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Preface 


The  following  document  is  the  culmination  of  the  work  performed  by  a  team  of 
eight  graduate  engineering  students  assigned  to  the  Air  Force  Institute  of  Technology 
(AFIT).  The  students  compiled  this  document  while  performing  a  systems  engineering 
design  study  to  create  a  small  standardized  tactical  satellite  bus  for  the  Phillips 
Laboratory.  This  document  is  divided  into  three  separate  volumes.  Each  volume  is  an 
integrated  element  of  the  student  thesis  but  it  can  also  serve  as  a  stand  alone  document. 

The  first  volume  is  the  Executive  Summary.  The  purpose  of  the  Executive 
Summary  is  to  present  a  synopsis  of  the  design  study  results  to  the  sponsor  at  the  Phillips 
Laboratory.  This  volume  includes  information  on  the  methods  employed  during  the  study, 
the  scope  of  the  problem,  the  value  system  used  to  evaluate  alternatives,  tradeoff  studies 
performed,  modeling  tools  utilized  to  create  and  analyze  design  alternatives, 
recommendations  and  implications  of  the  alternatives,  and  areas  where  future  research 
should  be  considered. 

The  second  volume  is  a  detailed  account  of  the  design  process.  The  steps  of  the 
team’s  innovative  design  process  and  the  team  organization  are  initially  presented.  Each 
phase  of  the  design  study  is  discussed  in  subsequent  sections.  Phase  I  provides  accounts 
of  the  team’s  initial  attempt  to  apply  a  well  known  systematic  approach  to  satellite  design. 
Efforts  concentrate  on  defining  the  problem  posed  by  the  sponsor.  ‘Tirst  cuts”  at 
developing  analysis  tools  and  models  are  performed.  Additionally,  different  alternatives 
are  generated  as  possible  solutions  to  the  problem.  An  initial  analysis  and  evaluation  is 
performed  to  define  an  initial  solution  space,  and  to  verify  the  analysis  tool.  Phase  11  is  an 
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iterative  step  in  the  design  process  and  serves  as  a  reservoir  for  the  team’s  most 
meaningful  work.  The  team  realized  that  a  new  systematic  approach  had  to  be  applied  to 
the  study.  This  phase  provides  the  results  of  the  application  of  that  innovative  approach. 

It  is  here  that  the  understanding  of  the  problem  is  further  refined  and  decisions  are  made 
that  limit  the  scope  of  the  study.  The  objective  hierarchy  is  further  developed  and  a  value 
system  is  created  as  a  method  for  measuring  each  design  alternative.  Information  is 
collected  on  satellite  designs  and  satellite  subsystems.  Tradeoffs  are  performed  to 
determined  the  best  methods  and  components  to  be  used  in  the  alternatives.  A  model  is 
created  and  design  alternatives  are  generated.  System  analysis  is  performed  on  the 
alternatives  using  the  value  hierarchy,  and  results  are  generated.  Sensitivity  analysis  is 
performed  on  the  alternatives,  and  implementation  recommendations  are  provided  to  the 
sponsor. 

The  third  volume  provides  details  on  the  tools  developed  to  build  a  satellite  and  to 
analyze  the  design.  There  are  three  sections  to  this  volume.  The  first  section  describes  the 
model’s  philosophy  and  presents  details  on  the  purpose  and  operation  of  each  module  of 
the  model.  Mathematical  formulae  and  module  architecture  are  also  described  in  this 
section.  The  second  section  is  a  user’s  guide  to  operating  the  model.  Specific  details  of 
the  sequence  to  be  used  and  information  required  to  run  the  model  are  provided  in  this 
discussion.  The  final  section  of  this  volume  is  the  actual  code  of  the  model.  The  code  is 
contained  in  an  annex  and  is  maintained  by  AFIT’s  Aeronautics  Department  at  Wright- 
Patterson  AFB,  Ohio.  The  code  can  be  provided  to  allow  future  modelers  to  understand 
and  refine  the  work  that  has  been  accomplished. 
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Abstract 

A  PRELIMINARY  DESIGN  OF  A  STANDARDIZED  SPACECRAFT  BUS  FOR 

SMALL  TACTICAL  SATELLITES 

Current  satellite  design  philosophies  concentrate  on  optimizing  and  tailoring  a  particular 
satellite  bus  to  a  specific  payload  or  mission.  Today's  satellites  take  a  long  time  to  build, 
checkout,  and  launch.  Space  Operations  planners,  concerned  with  the  unpredictable 
nature  of  the  global  demands  placed  upon  space  systems,  desire  responsive  satellite 
systems  that  are  multi-mission  capable,  easily  and  inexpensively  produced,  smoothly 
integrated,  and  rapidly  launched.  This  emphasis  shifl;s  the  design  paradigm  to  one  that 
focuses  on  access  to  space,  enabling  tactical  deployment  on  demand  and  the  capability  to 
put  current  payload  technology  into  orbit,  versus  several  years  by  today's  standards,  by 
which  time  the  technology  is  already  obsolete.  This  design  study  applied  systems 
engineering  methods  to  create  a  satellite  bus  architecture  that  can  accommodate  a  range  of 
remote  sensing  mission  modules.  System-level  and  subsystem-level  tradeoffs  provided 
standard  components  and  satellite  structures,  and  an  iterative  design  approach  provided 
candidate  designs  constructed  with  those  components.  A  cost  and  reliability  trade  study 
provided  initial  estimates  for  satellite  performance.  Modeling  and  analysis  based  upon  the 
Sponsor’s  objectives  converged  the  designs  to  an  optimum  solution.  Optimum  design 
characteristics  include  a  single-string  architecture,  modular  solar  arrays,  an  internet-style 
command  and  data  handling  system,  on-board  propulsion,  and  a  cage  structure  with  a 
removable  frame  for  easy  access  to  subsystem  components.  Major  products  of  this  study 
include  not  only  a  preliminary  satellite  design  to  meet  the  sponsor’s  needs,  but  also  a 
software  modeling  and  analysis  tool  for  satellite  design,  integration,  and  test.  Finally,  the 
report  provides  an  initial  implementation  scheme  and  concept  for  operations  for  the 
tactical  support  of  this  satellite  system. 


Authors: 


Committee: 

Sponsor: 


Capt  Gerald  F.  Ashby 
Capt  Darren  J.  Buck 
1st  Lt  Robert  W.  Cameal  IV 
1st  Lt  Tansel  Cokuysal 
1st  Lt  A.  Tuna  Donmez 
Capt  James  A.  From 
Capt  Todd  C.  Krueger 
ILt  Brian  I.  Robinson 

Lt  Col  Stuart  Kramer,  Maj  Ed  Pohl,  Dr  Chris  Hall 
Lt  Col  James  Rooney,  PLAVS 


1.  Report  Overview 


This  document  provides  the  results  of  a  group  design  study  performed  at  the  Air 
Force  Institute  of  Technology.  The  team  of  eight  graduate  engineering  students  examined 
the  design  of  a  generic  satellite  bus  for  small  tactical  satellite  applications.  The  project  was 
sponsored  by  LtCol  James  Rooney  of  the  United  States  Air  Force’s  Phillips  Laboratory  in 
Albuquerque,  New  Mexico.  Similar  design  studies  have  been  completed  by  various 
companies  and  laboratories,  but  to  date  success  has  been  limited.  Phillips  Laboratory’s 
goal  was  to  seek  a  “clean-sheet”  approach  to  the  design  of  a  cost-effective  satellite  bus. 
Several  design  characteristics  were  suggested  by  the  sponsor  and  were  considered 
throughout  the  project.  These  characteristics  included  modularity,  flexibility,  robustness, 
and  operability.  These  characteristics  have  been  treated  as  guidance  in  developing 
objectives  and  alternative  design  architectures  and  were  not  treated  as  hard  requirements. 

This  is  the  first  volume  of  a  three  volume  report.  Volume  I  is  an  Executive 
Summary  of  the  work  performed  by  the  design  team.  Volume  II  provides  greater  detail  of 
the  work  and  includes  the  theory  and  analysis  behind  the  team’s  approach  to  the  problem. 
Volume  III  is  an  in-depth  explanation  of  the  modeling  performed  for  the  project  and 
includes  the  associated  code. 

This  volume  provides  a  high  level  discussion  of  the  results  of  the  team’s  efforts. 
The  first  section  discusses  the  design  process  that  evolved  during  this  study.  The 
remaining  sections  document  the  results  in  each  of  the  steps  of  the  systematic  process. 
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A  majority  of  the  work  was  performed  in  the  second  iteration  of  the  design  study. 
This  volume  presents  this  information  and  contains  a  discussion  on  the  scope  of  the 
problem,  the  value  system  design,  the  decisions  made  in  the  tradeoffs  section,  and  an 
overview  of  the  modeling  efforts.  Different  design  alternatives  are  presented  in  system 
synthesis  and  the  analysis  of  the  alternatives  are  documented  in  the  system  analysis 
section.  Sensitivity  analysis  is  included  as  part  of  decision  making  and  the  implementation 
plan  discusses  how  the  selected  alternative  can  be  integrated  into  space  operations.  The 
final  section  of  this  report  provides  a  discussion  on  future  technologies  and  areas  where 
further  research  can  enhance  the  products  of  this  study. 
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2.  Design  Process 


The  design  team  recognized  the  need  for  a  well-defined,  iterative,  systematic 
design  process  to  approach  the  problem  logically.  The  design  team  was  familiar  with  two 
well-known  systematic  approaches,  Hall’s  seven-step  process  to  systems  engineering 
(Hall,  1969;  156)  and  the  space  mission  design  approach  described  in  the  Space  Mission 
Analysis  and  Design  (SMAD)  textbook  (Wertz  and  Larson,  1992: 1). 

Hall’s  systematic  process  has  been  a  standard  systematic  approach  for  almost  four 
decades.  This  process  is  well  understood  and  can  be  applied  to  many  different  engineering 
problems.  The  Hall  method  is  an  iterative  seven-step  process  (refer  to  Figure  2-1).  These 
steps  are:  problem  definition,  value  system  design,  system  synthesis,  system  analysis, 
optimization,  decision-making  and  implementation  (Hall,  1969:157). 


Figure  2-1:  Hall's  Seven-step  Approach 


Each  step  of  Hall’s  approach  is  influenced  by  the  actions  taken  in  the  other  steps. 
The  process’  iterative  nature  forces  refinement  in  each  step  as  the  process  continues. 
Hall’s  fundamental  framework  follows  a  logical  sequence  that  allows  the  user  to  define 
and  constrain  the  problem,  create  an  evaluation  tool  using  the  decision-maker’s  values, 
and  generate  possible  solution  alternatives.  The  framework  also  permits  the  user  to  create 
models  and  perform  simulations  as  a  means  of  quantifying  aspects  for  each  alternative. 

The  quantified  values  serve  as  an  input  into  the  evaluation  tool.  Once  the  basic  modeling 
is  accomphshed,  different  aspects  of  each  possible  solution  are  further  refined  in  an 
attempt  to  optimize  each  alternative.  Hall’s  process  also  allows  the  user  to  perform 
sensitivity  analysis  on  each  of  the  alternatives  before  the  decision-maker  is  presented  with 
the  results  of  the  system  evaluation.  In  the  decision-making  step,  the  decision-maker 
applies  his  subjective  values  and  risk  preferences  to  select  an  alternative.  With  an 
alternative  selected,  a  plan  for  implementation  is  created.  The  Hall  process  is  complete 
once  an  adequate  implementation  strategy  is  accepted  by  the  decision-maker. 

The  SMAD  approach  is  well-known  to  contemporary  satellite  designers  (Warner, 
1996).  The  SMAD  text  and  the  process  it  describes  is  a  compilation  of  the  first  thirty 
years  of  satellite  design  experience.  In  general  terms,  the  SMAD  process  can  be 
considered  the  classic  approach  to  satellite  design  because  the  approach  is  based  on  the 
premise  that  the  satellite’s  mission  drives  the  design  of  the  satellite  bus.  The  SMAD 
approach  is  iterative  and  consists  of  four  broad  areas.  These  broad  areas  are  1)  define 
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objectives,  2)  characterize  the  mission,  3)  evaluate  the  mission,  and  4)  define  requirements 
(Wertz  and  Larson,  1992:2). 


Table  2-1:  Space  Mission  Analysis  and  Design  Process 


■-  s 

tep  i 

'  Sub-steps .  1 

Define  Objectives 

; 

! 

[ 

A.  Define  broad  objectives  and  constraints  I 

B.  Estimate  quantitative  mission  needs  and  requirements 

Characterize  the  Mission 

! 

! 

1 

! 

C.  Define  alternative  mission  concepts 

D.  Define  alternative  mission  architectures 

E.  Identify  system  drivers  for  each 

F.  Characterize  mission  concepts  and  architectures  | 

1  Evaluate  the  Mission 

I 

G.  Identify  driving  requirements 

i 

H.  Evaluate  mission  utility 

i 

I.  Define  mission  concept  (baseline)  i 

Define  Requirements 

J.  Define  system  requirements  | 

K.  Allocate  requirements  to  system  elements  1 

The  first  step  in  the  SMAD  process  is  to  define  the  broad  mission  objectives  and 
constraints.  Additionally,  quantified  estimates  of  how  well  one  wants  to  achieve  the  broad 
mission  objectives  are  developed  with  respect  to  the  needs,  constraints,  and  technology 
available.  These  estimates  become  initial  system  requirements.  A  unique  feature  of  the 
SMAD  process  is  that  these  quantified  estimates  are  subject  to  trades  as  the  process 
continues.  Characterizing  the  mission  involves  a  number  of  steps.  These  steps  include 
defining  alternative  mission  concepts  and  architectures,  identifying  system  drivers  for  each 
alternative,  and  describing  in  detail  what  the  system  is  and  what  it  does.  Power,  weight, 
and  pointing  budgets  are  developed  in  this  step.  Evaluating  the  mission  forces  the 
designer  to  return  to  the  initial  system  requirements  to  determine  which  requirements 
become  driving  requirements.  Driving  requirements  are  the  items  principally  responsible 
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for  determining  the  cost  and  level  of  complexity  of  the  system.  Mission  utility  analysis  is 
also  part  of  this  step  and  this  analysis  quantifies  how  well  the  satellite  design  meets  the 
system  requirements  and  objectives  as  a  function  of  design  choices.  Evaluation  of  the 
mission  ends  by  choosing  a  baseline  system  design.  The  SMAD  process  ends  by  defining 
requirements.  Broad  objectives  and  constraints  are  translated  into  well-defined,  specific 
system  requirements.  These  numerical  requirements  are  allocated  to  specific  components 
of  the  overall  space  mission  (Wertz  and  Larson,  1992:3-90). 

The  traditional  approaches  are  not  suited  to  designing  a  satellite  bus  that  will 
support  a  variety  of  missions.  This  was  recognized  as  the  study  evolved  and  initial 
iterations  of  the  applied  processes  failed  to  narrow  the  scope  of  the  study.  Specifically, 
Hall’s  approach  does  not  provide  an  effective,  streamlined  method  for  converging  on 
viable  satellite  design  alternatives,  Time  is  wasted  performing  numerous  iterations  of  the 
process  to  achieve  the  desired  focus.  Likewise,  the  SMAD  process  concentrates  too 
much  on  using  the  satellite’s  payload  (mission  module)  as  the  key  upon  which  the  satellite 
bus  is  designed.  Consequently,  neither  of  these  methods  is  adequate  for  designing  a 
generic,  standardized  satellite  bus.  A  new,  customized  approach  was  developed  that 
permitted  the  team  to  converge  quickly  on  a  satellite  bus  design  without  regard  to  a 
particular  mission  module  type.  The  systematic  process  that  was  created  is  a  synthesis  of 
the  methods  described  by  Hall  and  SMAD.  The  process  is  called  the  Modsat  approach. 


6 


Table  2-2:  Modsat  Systems  Approach 


Step'^ 

'Action. <./y  -y  ] 

Problem  Definition 

Scope  nature  of  problem  I 

Value  System  Design 

Capture  decision  maker’s  needs  and  goals;  create  j 

evaluation  structure  for  alternatives 

Trade  Studies 

Link  broad  design  decisions  directly  to  the  study’s 
goals  and  objectives 

Modeling 

Formulate  predictive  or  descriptive  tool(s)  to  j 

represent  activities;  analyze  various  configurations 

System  Synthesis 

Create  alternative  solution  sets 

System  Analysis 

Score  each  alternative  against  problem’s  evaluation 
structure 

Decision  Making 

Perform  sensitivity  analysis  on  solution  sets 

Implementation 

Develop  plans  for  fielding  the  selected  altemative(s) 

The  iterative  approach  is  comprised  of  eight  steps.  The  steps,  in  order,  are 
problem  definition,  value  system  design,  trade  studies,  modeling,  system  synthesis,  systems 
analysis,  decision-making,  and  implementation.  The  majority  of  these  come  directly  from 
Hall’s  seven-step  process.  The  items  that  distinguish  this  approach  ffom  Hall’s  approach 
are  the  inclusion  of  a  trade  studies  step  and  the  reordering  of  the  system  synthesis  and 
modeling  steps.  Additionally,  the  design  team’s  approach  does  not  include  an 
optimization  step.  This  process  distinguishes  itself  fi'om  the  SMAD  process  in  two  ways. 
The  systematic  approach  does  not  commit  its  focus  to  the  requirements  of  one  mission 
module  as  the  key  factor  for  satellite  bus  design.  Secondly,  the  process  specifically 
includes  a  method  for  evaluating  the  merits  of  each  design  alternative. 

Problem  definition  is  a  fundamental  first  step  of  any  systematic  process.  The 
Modsat  problem  definition  step  closely  follows  that  of  Hall.  The  purpose  of  this  step  is  to 
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define  and  constrain  the  problem.  A  result  of  this  step  is  a  succinct  statement  that 
identifies  the  goal  and  focus  of  the  study.  The  value  of  the  problem  definition  step  is  that 
it  serves  as  a  mechanism  to  define  the  system  boundaries,  identify  the  system  needs, 
alterables  and  constraints,  and  to  identify  the  system  actors. 

The  system  boundaries  define  the  environment  affecting  the  system.  A  distinction 
can  be  made  between  those  items  contained  within  an  internal  environment  and  those 
items  contained  in  the  external  environment.  Items  within  the  internal  environment  are 
factors  that  the  design  team  can  control.  Items  that  exist  in  the  external  environment 
influence  the  study  but  cannot  be  controlled  by  the  design  team.  The  distinction  between 
the  internal  and  external  environment  is  paramount  to  understanding  the  scope  and  focus 
of  the  project.  The  focus  of  the  study  can  be  narrowed  further  by  performing  iterations  on 
the  system  boundaries.  Needs  are  the  fundamental  requirements  that  the  decision-maker 
and  users  levy  on  the  system  and  are  crucial  in  determining  the  broad  objective  of  the 
study.  As  is  the  case  in  the  SMAD  process,  some  needs  serve  as  driving  requirements  for 
satellite  bus  designs.  Other  needs  may  be  traded  off  against  each  other.  Alterables  are 
those  items  that  can  be  influenced  or  changed  by  the  design  team  and  are  contained  within 
the  internal  environment  of  the  system’s  boundaries.  Constraints  are  those  items  that  the 
team  cannot  control  but  have  a  major  impact  on  focusing  the  study.  Problem  definition 
also  identifies  the  actors  in  the  study.  Actors  are  simply  the  persons/groups  who  influence 
the  design  and  evaluation  of  possible  alternatives.  Different  tools  such  as  concept  maps. 
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waterfall  diagrams,  and  interaction  matrices  can  be  used  to  assist  in  defining  the  system 
boundaries,  needs,  alterables,  constraints,  and  actors. 

The  value  system  design  step  is  similar  to  Hall’s  respective  step.  The  purpose  of 
this  step  is  to  capture  the  decision-maker’s  values  and  goals.  Ultimately,  these  values  and 
goals  are  used  as  a  means  for  evaluating  the  effectiveness  of  design  alternatives. 

Capturing  the  decision-maker’s  values  and  goals  is  accomplished  by  creating  an  objective 
hierarchy.  Broad  values  and  goals  are  translated  into  broad  objectives.  The  broad 
objectives  are  decomposed  into  more  specific  subobjectives  until  meaningful  measures  of 
effectiveness  can  be  determined.  The  study’s  objectives  and  subobjectives  are  related  to 
the  needs,  alterables,  and  constraints  defined  in  the  previous  step.  As  part  of  defining  the 
study’s  objectives  and  measures  of  eflfectiveness,  major  premises  and  assumptions  are 
explicitly  articulated. 

Once  the  objective  hierarchy  is  in  place  the  decision-maker’s  preferences  for  each 
objective  have  to  be  incorporated  into  the  structure.  It  is  common  to  have  competing 
objectives  for  a  problem  or  study.  A  score,  or  weight,  is  assigned  to  each  objective  per 
level  in  the  hierarchy  to  capture  the  importance  the  decision-maker  places  on  a  particular 
objective.  The  weights  are  normalized  and  the  resulting  weighted  objective  hierarchy 
eventually  serves  as  the  evaluation  structure  for  each  solution  alternative  generated  in  the 
problem. 

The  trade  studies  step  is  a  new  and  innovative  step.  This  step  evolved  out  of  the 
SMAD  process.  The  purpose  of  the  trade  studies  step  is  to  make  broad  design  decisions 
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that  can  be  directly  linked  to  the  study’s  goals  and  objectives.  The  emphasis  is  on 
decisions  which  can  be  made  without  having  detailed  descriptions  of  the  alternatives. 
Trade  studies  serve  as  an  efficient  and  effective  means  to  narrow  the  study’s  scope  and 
provide  clearer  focus  early  in  the  design  process.  The  step  is  efficient  because  a 
manageable  study  focus  can  be  reached  without  the  need  for  extra  iterations  of  the 
process.  The  step  is  effective  because  it  reduces  the  number  of  possible  design 
alternatives  that  would  have  to  be  evaluated  to  determine  a  solution  to  the  study. 

The  trade  studies  occur  on  two  levels;  the  system  level  and  the  subsystem  level. 
Trades  performed  on  the  system  level  have  broader  effects  on  the  design  of  a  satellite  bus. 
These  system  level  trades  add  definition  to  the  external  environment  by  providing 
constraints  on  the  system’s  boundaries.  System  level  trade  decisions  also  impact  the 
trades  performed  on  the  subsystem  level. 

A  satellite  bus  is  a  system  comprised  of  smaller  subsystems.  Each  subsystem  can 
be  designed  in  a  variety  of  configurations  using  different  qualities  and  types  of 
components.  Some  choices  can  be  made  independent  of  choices  in  other  subsystems.  A 
subsystem  design  decision  that  is  traceable  to  the  study’s  goals  and  objectives  increases 
the  possibility  that  system  design  alternatives  will  meet  the  goals  of  the  study.  Defining  a 
subsystem  configuration  or  specifying  a  particular  quality  or  type  of  component  reduces 
the  number  of  iterations  a  designer  may  have  to  perform  to  create  a  viable  design 
alternative.  An  additional  benefit  of  including  a  trade  studies  step  early  in  the  process  is 
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that  it  forces  team  members  to  focus  efforts  on  gaining  insight  into  subsystem  design  while 
simultaneously  refining  the  problem. 

Although  the  trade  studies  step  evolved  fi'om  SMAD,  it  differs  fi’om  the  SMAD 
process  in  two  ways.  System  level  trades  in  SMAD  occur  late  in  the  process  (the 
“evaluate  the  mission”  step).  This  results  in  the  study’s  focus  and  system  boundaries  not 
being  fully  defined  until  late  in  the  process.  Subsequently,  time  is  wasted  early  in  the 
process  by  identifying  the  principal  cost  and  performance  drivers  for  each  mission  concept 
and  mission  architectures  alternative  before  the  system’s  boundaries  are  defined. 

Secondly,  SMAD  does  not  specifically  mention  that  subsystem  level  trades  would  occur  in 
the  process.  It  can  be  inferred  that  the  subsystem  level  trades  would  occur  after  the 
baseline  concept  is  determined. 

The  next  step  in  the  approach  is  modeling.  Modeling  is  the  development  of  a 
descriptive  or  predictive  model  representing  a  set  of  activities  or  the  entire  system  in  order 
to  allow  analysis  of  alternative  configurations  of  the  system  (Mosard,  1982:86).  The 
modeling  step  precedes  the  system  synthesis  step,  unlike  Hall’s  traditional  approach.  This 
reordering  of  process  steps  is  because  the  creation  and  development  of  satellite  bus  design 
alternatives  is  tedious  and  complex.  Satellite  design  is  an  art  because  many  satelUte 
components  have  to  be  strategically  placed  within  the  confines  of  a  satellite  structure  to 
meet  stringent  heat  dissipation,  thermal  shielding,  center  of  mass,  volume,  mass,  and  size 
constraints.  Modeling  provides  a  tool  that  permits  the  three-dimensional  visualization  of 
the  placement  and  performance  of  components.  Components  can  be  placed,  moved,  and 
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resized  quite  easily  using  a  model  when  compared  to  physically  connecting,  disconnecting, 
or  replacing  components  on  an  actual  satellite.  Time  and  cost  savings  can  be  easily 
realized  through  the  use  of  a  model,  especially  if  design  requirements  or  assumptions 
change. 

In  addition,  the  model  builder  can  take  advantage  of  the  decisions  that  have 
already  been  accomplished  during  the  process.  Desired  subsystem  configurations  and 
component  selection  fi-om  the  trade  studies  step  can  be  easily  loaded  into  the  model  before 
alternatives  are  created.  If  component  selection  changes,  the  new  information  can  be 
easily  loaded  into  the  model.  Modeling  must  also  be  able  to  quantify  the  performance 
characteristics  of  each  design  alternative.  Different  subsystem  characteristics  can  be 
emulated  using  mathematical  models  that  can  be  programmed  into  the  tool.  The  team’s 
modeling  section  currently  uses  the  first  order  estimates  and  relationships  that  are  found  in 
the  SMAD  process.  Refinements  to  these  relationships  can  be  loaded  into  the  model  as 
the  design  develops.  As  a  minimum,  the  quantified  performance  values  must  be  those 
values  necessary  for  input  into  the  value  system’s  measures  of  effectiveness. 

The  model  must  allow  analysis  of  alternative  configurations  of  the  system.  The 
evaluation  structure  developed  in  the  value  system  design  is  incorporated  into  this  stage  of 
the  process.  This  puts  an  evaluation  structure  in  place  before  any  design  alternatives  are 
generated.  With  effective  use  of  the  modeling  tool,  it  is  possible  to  create  new  designs 
and  perform  evaluation  on  those  designs  in  a  timely  fashion. 
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The  system  synthesis  step  is  similar  to  most  systematic  approach  steps  for  creating 
alternatives.  Accordingly,  alternatives  can  be  existing  designs,  modifications  to  existing 
designs,  prepackaged  designs,  or  entirely  new  designs  (Pohl,  1995).  The  difference 
between  the  system  synthesis  step  and  traditional  steps  is  its  placement  after  the  modeling 
step,  for  the  reasons  discussed  above. 

The  systems  analysis  step  follows  system  synthesis.  The  purpose  of  systems 
analysis  is  to  score  each  of  the  design  alternatives  against  the  problem’s  evaluation 
structure.  The  problem  has  been  defined  and  the  weighted  objective  hierarchy  is  in  place. 
Each  alternative’s  input  to  the  objective  hierarchy’s  measures  of  effectiveness  is  evaluated 
and  each  solution  alternative  receives  a  score  commensurate  with  its  performance  to  the 
competing  objectives. 

Decision-making  is  a  step  that  permits  the  team  to  perform  sensitivity  analysis  on 
the  design  alternatives.  Sensitivity  analysis  is  performed  by  varying  one  variable  at  a  time. 
This  variable  is  usually  a  weight  associated  with  an  objective  in  the  objective  hierarchy. 
The  results  of  the  sensitivity  analysis  provide  insight  as  to  how  an  alternative  will  perform 
given  different  preferences  of  the  decision-maker.  Including  the  sensitivity  analysis  results 
allows  the  decision-maker  to  make  a  subjective  decision  as  to  which  design  alternative  will 
meet  the  goals  of  the  study. 

Implementation  is  the  final  step  of  the  systematic  approach.  The  purpose  of  this 
step  is  to  develop  plans  for  fielding  the  selected  alternative.  The  plan  is  presented  to  the 
decision-maker  and  reflects  the  team’s  view  on  how  the  alternative  can  be  best  put  to  use 
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in  the  operational  setting.  It  provides  recommendations  for  improvements  to  the  selected 
alternative  and  to  the  associated  elements  that  affect  the  alternative.  The  implementation 
step  also  addresses  the  possible  architectures  in  which  the  alternative  can  be  deployed  and 
it  covers  the  organizational  structure  necessary  to  support  that  architecture. 

The  approach  described  above  is  an  innovative  approach  to  satellite  bus  design.  It 
provides  a  logical  sequence  which  deliberately  allows  the  design  to  evolve  from  one  stage 
to  another  while  documenting  the  decisions  and  assumptions  made  along  the  way.  The 
method  permits  continual  improvements  to  the  design  as  the  design  matures.  This 
approach  provides  a  method  for  determining  if  a  design  alternative  is  the  best  design 
possible  by  incorporating  design  decisions  made  throughout  the  process.  The  systematic 
approach  used  in  this  design  study  provides  a  holistic  view  of  the  problem  and  allows  the 
team  to  capture  all  important  aspects  affecting  the  design.  This  iterative,  systematic 
approach  ensures  that  these  aspects  are  correctly  integrated  throughout  the  design 
process. 
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3.  Team  Organization 


This  combined  approach  permitted  the  team  to  be  easily  divided  into  major  areas 
of  responsibility  within  a  matrix  organization.  The  team  concentrated  on  three  areas:  the 
major  steps  of  the  combined  Hall/SMAD  systematic  approach,  particular  satellite 
subsystems,  and  specific  areas  of  research.  Each  team  member’s  responsibility  included 
taking  the  lead  in  charting  the  group’s  direction  for  the  steps  of  the  Hall/SMAD  (reference 
Table  3-1)  while  maintaining  a  focus  on  the  team’s  limited  time,  resources,  and  budget. 
Decisions  made  in  one  area  of  the  design  or  a  step  in  the  process  had  to  be  properly 
documented  and  presented  to  the  group  to  prevent  conflicts  between  satellite  subsystems 
and  maintain  the  direction  of  the  project.  Team  members  also  provided  the  group  with  the 
information  necessary  to  understand  each  satellite  subsystem  and  to  realize  the  influence 
and  impact  each  subsystem  had  on  the  other.  The  subsystem  assignments  are  listed  in 
Table  3-2.  Each  member  also  made  contacts  with  aerospace  companies  or  organizations 
that  had  been  involved  with  the  development  of  satellites  within  the  project’s  weight  class 
(see  Table  3-3).  Extremely  valuable  information  was  gained  by  examining  the  successes 
and  failures  of  other  organizations.  The  following  three  tables  depict  the  structure  of  the 
team’s  matrix  organization. 


15 


Table  3-1:  System  Steps  Responsibility  Matrix 


Problem  Definition 

From/Krueger 

Value  System  Design 

Cokuysal 

Trade  Studies 

All 

Modeling/ Analysis 

Cameal/ Ashby 

System  Synthesis 

Buck 

Systems  Analysis 

Cameal/Ashby 

Decision  Making 

Donmez 

Implementation 

Donmez 

NOTE;  Robinson  served  as  a  “floater”  throughout  the  Hall/SMAD  approach. 


Table  3-2:  Subsystem  Expertise  Responsibility  Matrix 


Subsystem  Area  '  7" ',7^  - ■ 

Structures/Mechanisms 

and  Thermal  Control 

Ashby 

Electrical  Power  Generation  and 

Distribution 

Krueger 

Attitude  Determination  and  Control 

Robinson 

Propulsion 

Cokuysal 

Telemetry,  Tracking,  and 

Commanding/Data  Handling 

Cameal/From 

Mission  Modules 

Buck 

Launch  Systems/Command,  Control  and 
Communications/Operations  Concepts 

Donmez 
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Table  3-3:  Similar  Projects  Research  Responsibility 


Research  Area 

Spectrum  Astro/MSTI 

Cokuysal 

TRW  and  CTA/STEP 

Ashby 

Lockheed-Martin/Iridium 

Carneal 

Orbital  Sciences  Corporation/Pegasus 

Donmez 

AeroAstro/HETE 

From 

Ball  Aerospace 

Buck 

Naval  Research  Laboratory\Clementine 

Robinson 

Phillips  Laboratory/MightySat 

Krueger 
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4.  Problem  Deflnition 


4.1  Deflnition 

Problem  definition  was  the  first  step  of  the  systematic  approached.  The  purpose  of 
the  problem  definition  step  was  to  evaluate  the  proposed  problem  and  establish  a  succinct 
problem  statement.  Defining  the  problem  required  careful  examination  of  the  sponsor’s 
tasking  statement  and  the  factors  influencing  the  proposed  problem.  Identification  of  the 
system’s  boundary,  needs,  alterables,  constraints,  and  actors  were  important  to 
understanding  the  scope  of  the  problem. 

The  system’s  boundary  defined  those  elements  of  the  problem,  and  its  potential 
solution  space,  that  could  or  could  not  be  controlled  or  manipulated  by  the  design  team 
(Athey,  1992;  13).  Through  careful  examination  and  identification  of  the  problem’s 
boundary,  the  design  team  determined  the  factors  that  influence  and  affected  the  problem. 

Needs  were  the  driving  factors  behind  the  existence  of  the  problem.  Needs  were 
referred  to  as  requirements.  Without  the  needs,  there  would  have  been  no  problem.  By 
identifying  the  needs  of  the  chief  decision  maker  (CDM),  the  team  understood  why  the 
problem  existed,  what  the  problem  was,  and  what  some  of  the  possible  solutions  to  the 
problem  were.  Needs  also  served  as  a  means  for  measuring  the  success  of  potential 
solutions. 

Alterables  were  those  factors  the  CDM  had  control  over.  Identifying  those  factors 
provided  the  team  with  a  method  of  opening  the  potential  solution  space  to  the  problem. 
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Constraints,  on  the  other  hand,  were  factors  that  the  CDM  and  design  team  had  no  control 
over.  These  factors  limited  the  number  of  potential  solutions  to  the  problem. 

Actors  were  the  people  who  had  an  influence  on  the  problem  and  the  possible 
alternatives.  The  most  influential  actor  was  the  chief  decision  maker.  Capturing  and 
incorporating  the  decision  maker’s  needs,  values,  and  constraints  was  paramount  to 
producing  the  best  solution  possible.  The  decision  maker  provided  information  necessary 
to  determine  the  framework  by  which  all  possible  alternatives  were  measured. 

Gaining  insight  into  satellite  design  and  probing  the  different  aspects  of  the 
proposed  problem  were  the  main  focus  of  the  first  iteration.  In  the  second  iteration,  the 
team  focused  its  effort  on  studying  and  understanding  the  functions  of  the  satellite 
subsystems  and  examining  the  factors  that  influence  the  satellite  bus  design.  This  led  to  a 
more  detailed  examination  of  the  tasking  statement  and  the  factors  that  influence  the 
problem. 

The  resulting  problem  statement  was  referred  to  throughout  the  design  process. 
This  ensured  that  the  team’s  efforts  remained  focused. 

4.2  Problem  Statement 

The  problem  statement  reads: 

Design  a  rapidly  deployable,  tactically  oriented,  satellite  bus  to  enhance  theater 
operations.  This  satellite  bus  is  to  support  missions  in  the  Pegasus  and  Lockheed-Martin 
Launch  Vehicle  (LMLV)  weight  class. 
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4.3  Concept  Map 


A  concept  map  was  employed  to  help  define  the  problem.  The  concept  map 
provided  a  graphic  representation  of  the  design  team’s  interpretation  of  the  problem. 
Concept  mapping  is  based  on  the  premise  that  all  knowledge  can  be  represented  by 
relationships  between  more  fimdamental  concepts  (Kramer,1990:652-654).  The  concept 
map  consists  of  two  primitives:  concepts  and  linkages.  As  an  example,  refer  to  Figure  4- 
1.  The  satellite  bus  is  the  central  concept.  The  motherboard  architecture  is  another 
concept.  The  device  which  connects  the  two  is  the  linkage.  The  linkage  in  this  case  is 
“has  a”.  This  method  ties  the  two  concepts  together  into  a  meaningfiil  structure. 

The  team  developed  the  concept  map  in  Figure  4-1  by  carefully  evaluating  the 
concepts  and  linkages  suggested  through  the  chief  decision  maker’s  tasking  statement. 
This  graphic  represented  the  design  team’s  interpretation  of  the  decision  maker’s  problem. 
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Figure  4-1:  Concept  Map  of  Problem 

The  use  of  the  concept  map  provided  many  benefits.  It  helped  the  team 

understand  how  various  factors  affected  the  problem.  The  team  immediately  realized  that 
the  problem  was  highly  complex.  The  concept  map  generated  many  questions  the  team 
needed  answered  before  a  concentrated  approach  to  the  solution  could  be  given.  The 
team  began  to  question  how  the  operations  concept  affected  a  satellite  design.  How 
would  integration  and  launch  processing  occur?  Was  launch  vehicle  selection  an  area  to 
be  explored?  Another  question  centered  on  what  type  of  components  were  “off-the-shelf’ 
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and  what  reliability  did  they  have.  The  team  also  wanted  to  know  what  effect  orbit 
selection  might  have  on  vehicle  life  time. 

The  concept  map  helped  the  team  identify  issues  that  needed  to  be  considered 
when  examining  candidate  solutions.  The  team  began  to  question  how  much  modularity  is 
needed  in  a  satellite  bus  design  and  whether  modularity  is  necessarily  good.  Other 
questions  focused  on  how  much  autonomy  a  satellite  bus  needs  and  what  reliability  is 
required  for  a  one  year  life  time. 

The  use  of  the  concept  map  was  only  a  starting  point.  The  team  realized  that 
much  research  was  needed  to  fully  understand  the  problem.  Questions  prompted  through 
the  use  of  the  concept  map  were  instrumental  in  identifying  areas  where  research  needed 
to  be  performed.  These  areas  included  researching  similar  projects,  satellite  subsystems, 
launch  vehicles,  satellite  design  concepts,  command,  communication  and  control 
architectures,  orbital  mechanics,  and  potential  mission  modules.  The  concept  map  offered 
yet  another  benefit.  This  representation  of  the  problem  provided  a  potential  mechanism 
for  the  team  and  the  decision  maker  to  fully  discuss  what  the  problem  was  and  what  it  was 
not.  The  definition  of  the  problem  was  further  enhanced  by  establishing  system 
boundaries. 

4.4  System  Boundary 

Since  the  system  boundary  defined  the  elements  of  the  problem  that  could  be 
controlled  or  manipulated,  the  team  decided  that  the  best  way  to  narrow  the  focus  and 
scope  of  the  study  was  to  refine  this  area.  The  boundaries  were  divided  into  two  distinct 


22 


environments;  an  external  environment  and  an  internal  environment.  Items  that  existed  in 


the  external  environment  influenced  the  solution  space  for  the  problem,  but  were  not  items 
that  the  design  team  could  control.  These  items  were  considered  outside  the  team’s  scope 
with  respect  to  redesigning  components  or  changing  concepts  of  operation.  Items 


contained  within  the  internal  environment  were  aspects  that  could  be  controlled  by  the 
design  team  and  were  subject  to  trade  studies  Figure  4-2  provides  a  graphical 
representation  of  the  problem’s  system  boundaries. 


The  external  boundary  was  comprised  of  the  following  items:  the  launch  vehicle, 
the  payload,  the  satellite  contractor,  the  mission  operations  concept,  the  space 
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environment,  the  constellation  design,  the  storage  and  inventory  concept,  and  the  Air 

Force  Satellite  Control  Network.  Aspects  of  each  element  are  described  below. 

•  The  launch  vehicle:  The  design  team  examined  the  system  requirements  for  placing 
the  vehicle  into  orbit.  The  team  decided  to  use  the  Pegasus  XL  launch  vehicle  for  this 
design  study.  Aspects  of  the  launch  vehicle  that  had  an  influence  on  the  satellite  bus 
design  were  launch  preparation  time,  mass-to-orbit  performance,  satellite-to-launch 
vehicle  integration  constraints,  and  fairing  constraints.  Launch  vehicle  development 
and  integration  of  launch  vehicle  stages  were  outside  the  realm  of  the  design  team’s 
control  and  were  not  subjected  to  trades  or  redesign. 

•  The  mission  module:  A  number  of  different  mission  modules  were  examined.  These 
included  remote  sensing  payloads  such  as  multispectral  imaging  (MSI)  systems, 
synthetic  aperture  radar  (SAR)  systems,  infrared  (IR)  systems,  and  laser  designators. 
Specific  mission  modules  were  not  designed  by  the  team  to  be  integrated  onto  the 
generic  bus.  The  bus  design  was  influenced  by  the  mission  module’s  data 
storage/health  and  status  requirements,  thermal  loading,  power  requirements,  mission 
requirements,  and  required  pointing  accuracy’s. 

•  The  satellite  contractor:  A  satellite  company  has  a  definite  influence  on  the  design 
when  it  comes  to  manufacturing  the  actual  satellite  bus.  Additionally,  different 
companies  have  different  manufacturing  processes.  Due  to  the  preliminary  nature  of 
the  design  study,  the  team  considered  items  that  would  create  manufacturing 
difficulties,  but  did  not  perform  extensive  research  into  actual  satellite  manufacturing. 
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•  The  mission  operations  concept:  The  methods  the  United  States  Air  Force  (USAF) 
employs  to  perform  its  satellite  missions  had  an  influence  on  the  satellite  design.  The 
design  team  did  not  attempt  to  change  or  modify  the  way  the  USAF  does  business. 
However,  understanding  the  constraints  and  requirements  needed  to  perform  satellite 
operations  was  a  prerequisite  for  this  design  effort. 

•  The  space  environment:  This  was  the  actual  operating  environment  in  which  the 
satellite  bus  would  perform  its  mission.  It  was  important  that  the  design  team 
understood  what  effects  space  could  have  upon  the  satellite  bus.  The  team  had  to 
design  the  vehicle  in  such  a  way  that  it  accounted  for  the  space  environment. 

•  The  constellation  design:  The  actual  use  of  the  vehicle  and  constellation  deployment 
was  left  to  the  satellite  user.  The  orbit  choice  and  number  of  satellites  to  be  placed 
into  orbit  will  be  contingent  upon  the  user’s  need.  The  team  provided  a  satellite  bus 
design  that  attempted  to  maximize  its  utility  to  the  user. 

•  The  storage  and  inventory  concept:  It  was  taken  as  an  assumption  that  the  satellite 
and  its  components  would  be  stored  and  maintmned  in  an  appropriate  clean  room 
environment  while  the  satellite  was  on  the  ground.  Therefore,  the  team  did  not  design 
any  aspects  of  the  storage  and  inventory  process.  However,  consideration  was  given 
to  this  storage  and  inventory  process  when  design  alternatives  were  developed. 

•  The  Air  Force  Satellite  Control  Network  (AFSCNI:  Since  compatibility  with  the 
AFSCN  was  required  by  the  decision  maker,  aspects  associated  with  this  satellite 
control  network  had  a  major  influence  on  the  design.  Satellite  components  such  as 
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receivers  and  transmitters  had  to  operate  at  Space  Ground  Link  System  (SGLS) 
frequencies.  The  team  made  no  attempts  to  redesign  any  aspect  of  the  AFSCN. 

Items  contained  within  the  internal  environment  included  the  satellite  bus 
subsystems,  the  launch  vehicle  interface,  and  the  mission  module  interface.  Operational 
concepts  directly  related  to  the  use  of  the  bus  were  considered  within  the  boundary  of  the 
system.  The  team  had  the  freedom  to  modify  concepts  such  as  on-orbit  command  and 
control,  mission  module  and  launch  integration,  and  sensor  data  processing.  The  team 
decided  that  the  concept  of  having  two  different  on-orbit  command  and  control  systems  to 
the  satellite  was  well  within  the  scope  of  the  bus  design. 

4.5  Needs 

Revision  were  made  to  the  needs.  This  was  accomplished  because  the  team 
wanted  a  clearer  understanding  of  the  problem.  The  categorized  lists  created  in  the  first 
iteration  only  provided  generalized  groupings  of  the  needs.  A  deeper  understanding  of  the 
problem  required  more  definition  be  given  to  the  problems  needs.  It  was  believed  that  if  a 
needs  definition  could  be  tied  to  the  system’s  boundaries  or  the  decision  maker’s  views 
(Rooney,  1996),  it  would  offer  a  better  understanding  of  the  problem.  The  refined  needs 
definitions  are  provided  below  and  incorporate  the  sponsor’s  views  or  the  system’s 
boundary  considerations  as  appropriate. 

•  Mass:  The  satellite  design  had  to  be  optimized  to  support  as  many  mission  module 
types  as  possible.  Mission  modules  with  masses  between  23  and  114  kilograms  had  to 
be  supported  and  fit  within  the  constraints  of  a  Pegasus  XL  launch  vehicle.  It  was 
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thought  that  better  designs  would  provide  more  mass  and  volume  to  the  mission 
module  yet  still  supply  ample  power  and  interfaces. 

•  Responsiveness:  Possible  design  alternatives  had  to  consider  the  rapid  launch  of  a 
satellite  constellation.  The  bus/mission  module  combination  had  to  be  easily  integrated 
to  meet  the  need  for  rapid  deployability  and  tactical  applications. 

•  Sensors/mission  modules:  Different  mission  requirements  were  considered;  i.e., 
electro-optical  (EO),  infra-red  (IR),  laser  designators. 

•  Pointing  accuracy:  The  question  of  pointing  accuracy  had  to  be  considered  when 
trying  to  achieve  1  meter  resolution  during  an  imagery  pass  of  5-10  minutes  per  orbit. 

•  Power:  The  satellite  design  had  to  support  peak  power  requirements  up  to  1  kilowatts 
and  average  power  requirements  of  300-500  watts. 

•  Orbital  maintenance:  The  satellite  had  to  operate  at  a  minimal  orbital  altitude  of  3  00 
kilometers  for  a  mean  mission  duration  of  12  months. 

•  Telemetry-  Tracking,  and  Command:  Satellite  design  alternatives  had  to  be  compatible 
with  the  AFSCN.  Data  downlinks  had  to  support  near  real-time  transmission  of  1 
meter  resolution  imagery  data.  Encryption  and  deception  provisions  were  also 
required. 

•  Data  storage:  Designs  had  to  support  on-board  storage  of  up  to  100  images. 

•  Data  Processing:  Design  alternatives  had  to  support  minimal  on-board  processing  and 
data  compression  algorithms  for  transmission  of  images  to  ground  station. 
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4.6  Alterables  and  Constraints 

Alterables  were  those  elements  of  the  system  and  its  environment  that  could  be 
controlled  by  the  chief  decision  maker.  The  constraints  were  those  items  which  could  not 
be  changed  by  the  decision  maker.  The  team  had  to  manipulate  the  alterables  to  achieve  a 
solution,  provided  the  constraints  were  satisfied.  The  items  contained  within  the  internal 
environment  were  considered  the  alterables.  The  items  in  the  external  environment  were 
constraints  on  the  alternatives  for  the  design  study. 

4.7  Actors 

The  actors  were  all  the  people  and  agencies  who  were  involved  with  some  aspect 
of  the  system  or  project.  It  was  important  to  understand  and  consider  the  impact  the 
system  has  on  all  actors.  The  principle  actor  for  any  project  is  the  chief  decision  maker 
(CDM).  The  CDM  generates  the  requirements  and  objectives  for  the  system,  and  is  the 
approving  and  implementing  authority  for  the  solution.  The  CDM  for  this  project  was 
LtCol  James  Rooney  of  Phillips  Laboratory,  Kirtland  Air  Force  Base.  The  design  team 
was  comprised  of  the  engineers  and  analysts  who  will  work  together  to  develop  the 
system.  This  project’s  design  team  consisted  of  space  operations  and  systems  engineering 
masters  candidates  at  the  Air  Force  Institute  of  Technology  (AFIT).  The  team  was 
advised  by  members  of  AFIT’s  Department  of  Aeronautics/ Astronautics. 

The  eventual  user  of  bus  design  was  also  an  actor  in  this  design  study.  This  was 
the  warfighter  who  depended  on  tactical  space  assets  to  wage  effective  information 
warfare.  In  order  for  the  warfighter  to  receive  his  information,  the  project’s  satellites 
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would  be  commanded  and  controlled  by  Air  Force  space  operators.  Air  Force  launch 
personnel  would  integrate  the  satellites  to  launch  vehicles  and  launch  them  into  low  earth 
orbits.  Prior  to  launch,  mission  modules  would  be  integrated  with  their  satellite  busses  by 
qualified  personnel.  Prior  to  being  required  for  missions,  ready-to-integrate  busses  would 
be  stored  and  maintained.  All  personnel  required  to  complete  these  activities  were 
important  actors  in  the  development  of  this  system,  and  their  needs  were  considered. 

4.8  Mission  Module  Overview 

The  problem  involved  with  the  design  of  a  “generic”  satellite  bus  is  that,  because 
the  bus  is  to  be  generic,  it  cannot  be  designed  to  one  specific  payload  or  mission.  It  must 
support  the  requirements  demanded  by  all  foreseeable  missions  within  the  scope  of  the 
overall  design. 

4.8.1  Background  and  Scope 

The  payload  or  mission  equipment  of  any  spacecraft  is  generally  considered  to  be 
that  particular  spacecraft’s  reason  for  existing.  The  payload  is,  after  all,  comprised  of  the 
equipment  which  the  spacecraft  owners  and  users  desire  to  employ  (from  the  space 
vantage)  for  the  collection  or  distribution  of  very  specific  mission  information. 
Consequently,  satellite  designs  in  the  past  have  always  focused  on  this  specialized 
equipment,  functionally  separating  it  from  the  rest  of  the  vehicle  (satellite  bus).  Within 
this  paradigm,  payloads  tended  to  be  as  large,  expensive,  and/or  as  powerful  or  capable  as 
possible.  The  bus  was  basically  designed  and  built  to  support  that  particular  payload  (i.e., 
the  bus  was  built  up  “around”  the  payload).  Thus,  because  of  the  specific  nature  of  a 
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spacecraft’s  payload  equipment,  as  well  as  owing  to  the  fact  that  all  satellites  are  basically 
manufactured  by  hand,  individual  satellites  tended  (and  continue)  to  be  unique. 

Similarities  in  design  and  equipment  among  satelhtes  of  the  same  constellation  or  “family” 
are  more  numerous,  but  even  these  satellites  have  been  and  continue  to  be  dissimilar  in 
some  areas,  due  to  the  addition  of  features,  change  of  specifications,  or  flight  experience 
fi-om  earlier  designs.  All  of  these  factors,  in  addition  to  the  slow  historical  launch  rate, 
tended  to  drive  up  costs.  A  ‘Vicious  circle”  of  spiraling  costs  ensued  and  continues  today, 
driving  designers  to  build  fewer,  more  reliable,  more  capable,  and  larger  satellites.  The 
larger  vehicles  compounded  the  launch  availability  problem  due  to  the  fact  that  larger 
boosters  became  necessary  for  the  larger  vehicles  --  larger  boosters  take  longer  and  are 
more  costly  to  integrate. 

Shifting  equipment  and  design  focus  AWAY  from  the  payload  components  forces 
a  shift  in  the  spacecraft  design  paradigm.  It  focuses  on  the  vehicle  itself,  the  bus,  as  a 
starting  point  for  employment  of  special  sensors  or  other  equipment  fi-om  space.  In  this 
paradigm,  the  payload  simply  becomes  yet  another  “component”  which  must  be  integrated 
into  the  vehicle  as  a  whole  —  the  payload  specializes  or  tailors  a  standard  vehicle  to  a 
specific  mission  or  purpose.  This  paradigm  is  analogous  to  a  multi-role  fighter  aircraft 
being  outfitted  with  a  particular  weapons  load  for  the  performance  of  a  specific  mission. 
The  fighter  is  the  “standard  vehicle”  which  can  then  be  used  for  a  variety  of  missions. 

This  particular  paradigm  requires  the  payload  designer  to  produce  payload  equipment 
packages  which  can  seamlessly  interface  with  and  “take  a  ride”  on  a  satellite  bus  which  has 
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already  been  designed  (or  built)  and  can  provide  all  the  payload  support  functions 
necessary. 

The  aspects  of  the  satellite-to-mission  module  interface  which  will  be  most 
important  to  the  mission  module  designer  will  be  mass,  volume,  power,  and  data  storage 
budgets  available  for  the  mission  module.  These  budgets  will  provide  the  mission  module 
designer  with  limits  within  which  the  mission-specific  equipment  must  operate. 

Similarly,  the  most  important  considerations  for  the  bus  design  will  be  the  support 
of  those  baseline  power,  mass,  stability,  pointing,  data  handling,  data  storage,  and  thermal 
isolation  requirements  necessary  to  accommodate  all  of  the  baseline  mission  module  types. 
These  types  include  applications  spanning  basic  electro-optical  radiometers,  multispectral 
imagers,  LASER/LIDAR  systems,  and  synthetic  aperture  RADARs.  These  mission 
module  types  were  chosen  for  their  diversity  and  their  applicability  to  tactical  space 
applications.  Because  of  the  generic  nature  of  this  study,  and  due  to  the  fact  that 
specifications  for  military  systems  (within  these  categories)  are  either  classified  or 
unavailable  at  this  time,  estimates  for  mass,  power,  volume,  and  other  specific 
requirements  had  to  be  generated  from  experience,  remote  sensing  class  notes,  SMAD, 
and  the  few  analogous  commercial,  scientific,  and  civilian  apphcations  available  for 
inclusion.  For  purposes  of  this  design  study,  however,  which  focuses  on  the  design  of  a 
specific  satellite  bus  (not  the  mission  modules),  lack  of  specificity  of  mission  module 
designs  will  not  impact  the  overall  design  of  the  bus.  The  purpose  of  a  discussion  of 
mission  module  requirements  will  provide,  in  many  cases,  valuable  performance 
requirements  to  be  met  by  the  specific  subsystems  of  the  satellite  bus  (e.g.,  pointing 
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accuracy  requirements  will  drive  decisions  made  about  attitude  control  system 
components).  In  all  cases,  extrapolation  of  estimates  was  conservatively  overestimated  in 
order  to  provide  sufficient  design  margins. 

4.8.2  Specific  Mission  Module  Types 

4.8.2. 1  Electro-Optical  Imaging  (£0) 

The  least  expensive,  lightest  weight,  lowest  power,  and  probably  the  widest  used 
payload  type  for  tactical  missions  is  the  simple  yet  capable,  high-resolution  camera  system. 
The  military  utility  of  this  type  of  imagery  dates  back  to  the  first  days  of  placing  observers 
in  balloons  and  later  placement  of  cameras  in  reconnaissance  aircraft.  The  EO  mission 
module  is  very  closely  constrained  to  a  Sun-synchronous  orbit  for  optimal  orbit  selection, 
due  to  the  radiometric  equipment’s  dependence  upon  reflected  sunlight  for  illumination  of 
a  target. 

The  following  table  summarizes  some  estimated  EO  mission  modules  and  their 
characteristics.  For  the  EO  mission  module,  a  central  wavelength  of  0.5  microns  is 
assumed,  and  ground  resolution  is  calculated  based  on  a  350  km  circular  orbit. 

Table  4-1:  Electro-optical  (EO)  Mission  Module  Estimations 


Aperture 

(cm) 

Diffraction 

Resolution 

(mrad/m) 

Mass 

(kg) 

Volume 

(m3) 

Power 

(w) 

30 

2.03/0.71 

23 

0.035 

7.5 

40 

1.53/0.53 

41 

0.082 

10.0 

50 

1.22/0.43 

64 

0.158 

12.5 
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4.S.2.2  Multispectral  Imaging  (MSI) 


Advances  in  image  processing  as  well  as  improvements  in  detector  performance 
over  the  past  few  years  have  made  MSI  a  high-demand  payload.  The  MSI  mission  module 
uses  several  different  arrays  of  detectors  (CCD  arrays),  each  optimized  to  detect  a  specific 
band  of  EM  radiation.  Image  processing  produces  simultaneous  images  of  a  target  area 
characterized  at  various  regions  of  the  EM  spectrum.  Intensity  levels  at  specific 
wavelengths  may  indicate,  through  analysis,  a  particular  activity,  characteristic,  or  object 
within  the  field  of  view.  By  overlaying  and  comparing  the  levels  of  intensity  at  specific 
wavelengths  from  a  single  target,  many  characteristics  of  the  target  and  subsequent  target 
identification  may  be  determined  by  comparing  the  received  spectra  to  known  spectra 
(predetermined  spectra  for  specific  substances  —  a  particular  type  of  vehicle  paint,  for 
instance).  Due  to  its  wider  range  of  detectable  radiation  bands,  the  MSI  mission  module  is 
not  as  closely  constrained  to  the  Sun-synchronous  orbit,  although  this  type  of  orbit  is  still 
very  advantageous.  Specific  orbit  selections  for  MSI  mission  modules  will  vary,  in 
accordance  with  varying  detector  types  and  specific  mission  objectives. 

Physical  characteristics  for  the  MSI  mission  module  are  similar,  but  more  massive 
and  more  power-hungry,  than  the  EO  mission  module.  MSI  payload  characteristics  will 
vary  according  to  specific  design  and  performance  requirements. 

Estimates  for  MSI  mission  modules  and  their  vital  characteristics  are  included  in 
the  following  table.  Resolutions  are  calculated  from  a  350  km  circular  orbit. 
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Table  4-2:  Multispectral  Imaging  (MSI)  Mission  Module  Estimations 


Aperture 

(cm) 

NIR  (1.5pm) 
Diffraction 
Resolution 
(prad/m) 

MIR  (4.0pm) 
Diffraction 
Resolution 
(prad/m) 

LWIR  (10.0pm) 
Diffraction 
Resolution 
(prad/m) 

Mass 

(kg) 

Volume 

(m^) 

Power 

(w) 

30 

6.1/2.135 

16.3/5.69 

40.7/14.23 

28.5 

0.039 

60.0 

40 

3.75/1.3125 

12.2/4.27 

30.5/10.68 

50.3 

0.089 

80.0 

50 

3.0/1.05 

9,76/3.42 

24.4/8.54 

78.7 

0.169 

100 

4.8.2.3  LASER/LID AR  Applications 

Using  optics  similar  to  the  EO  package  (and  in  some  “functionally  dense”  mission 
modules,  the  VERY  same  optics  as  the  visible  camera/detector),  the  LASER  imaging 
payload  adds  a  LASER  head  and  power  supply  (LASER  pump)  in  order  to  illuminate  a 
target  with  a  specific  wavelength  of  EM  radiation.  These  payloads  can  produce  very 
accurate  three-dimensional  imagery,  making  them  well-suited  for  topographical  missions 
and  atmospheric/meteorological  (cloud  system)  observations. 

The  following  table  summarizes  some  estimated  LASER/LIDAR  mission  modules 
and  their  characteristics. 


Table  4-3:  LASER/LIDAR  Mission  Module  Estimations 


Aperture  (m) 

LASER  Power  (w) 

Mass  (kg) 

Volume  (m^) 

Power  (w) 

30 

300 

38.7 

0.044 

318 

40 

250 

56.7 

0.089 

274 
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4.8.2.4  Synthetic  Aperture  Radar  (SAR) 


By  far  the  payload  with  possibly  the  greatest  potential  tactical  “payoff’  is  the 
Synthetic  Aperture  RADAR  or  SAR  mission  module,  which  can  produce  (through 
intensive  image  processing)  very  high  resolution  images.  SAR  mission  modules,  like 
LASER-based  mission  modules,  are  active  sensing  systems  and,  as  such,  generally  require 
an  order  of  magnitude  greater  power  to  operate  than  passive  systems  (EO  and  MSI).  Day 
and  night,  all-weather  operations  are  possible  with  the  SAR  mission  module,  releasing  it 
from  a  “most  desired”  orbit  type. 

Some  estimated  SAR  mission  modules  (with  stowed  antenna  —  launch 
configuration)  are  summarized  in  the  following  table. 


Table  4-4:  Synthetic  Aperture  RADAR  (SAR)  Mission  Module  Estimations 


Antenna  Dimensions  (m  x  m) 

Mass  (kg) 

Volume  (m^) 

Power  (w) 

8.0  X  1.5 

78.4 

0.318 

800 

10.0x2.0 

86.5 

0.564  • 

450 

4.8.3  Generally  Specified  Mission  Module  Support  Requirements 

Though  the  aforementioned  mission  module  types  are  varied  (not  to  mention  those 
mission  modules  which  may  be  further  differentiated  (based  on  specialized  application) 
within  a  given  general  type),  there  are  certain  requirements  on  the  bus  which  may  be 
specified,  allowing  components  in  many  of  the  spacecraft  subsystems  to  be  chosen  for  all 
candidate  designs.  The  requirements  specifiable  through  mission  module  consideration 
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include  stabilization  control,  pointing  accuracy,  attitude  knowledge,  thermal  isolation, 
operating  power,  data  handling,  data  storage,  and  data  down-link. 

All  design  requirements  which  the  bus  must  meet  will  be  driven  by  the  most 
demanding  mission  module  type  in  all  cases.  Furthermore,  because  of  the  lack  of 
specificity  of  mission  module  designs,  those  driving  design  requirements  must  necessarily 
be  interpreted  as  “ranges”  of  values,  as  opposed  to  exact  quantities.  The  following  table 
summarizes  the  requirements  necessary  for  support  of  all  mission  module  types. 


Table  4-5:  Estimated  Mission  Module  Support  Requirements 


Bus  Performance  Criteria 

Mission  Module  Support  Requirement 

Pointing  Accuracy 

0.2-0. 1  degrees  or  better 

Attitude  Knowledge 

0.07-0.05  degrees  or  better 

Data  Compression 

4: 1  minimum 

Data  Storage  Capacity 

2Gbytes  minimum;  modular  unit 

Data  Handling  Capacity 

150  Mbytes/s  or  better 

Thermal  Environment 

thermally  isolated  from  mission  module 

Available  Mission  Power 

peak  power  from  500-900  watts 

Available  Mission  Launch  Mass 

120  kg  or  better 

Available  Mission  Launch  Volume 

0.6  m^  or  better 
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5.  Value  System  Design 


5.1  Overview 

A  systems  engineering  approach  to  the  development  of  a  system  considers  the 
values  and  objectives  of  the  chief  decision  maker  (CDM).  The  requirements  and  values 
expressed  by  the  CDM  must  be  expressed  as  an  organized  set  of  system  objectives.  This 
set  of  objectives  should  drive  all  design  efforts,  and  it  must  serve  as  the  standard  by  which 
alternative  solutions  are  evaluated.  Often,  the  established  objectives  are  in  conflict;  that  is, 
positive  performance  for  one  objective  may  imply  negative  performance  for  another.  An 
example  of  this  is  the  use  of  cutting-edge  technology,  which  may  deliver  high  performance 
while  admitting  higher  cost  and  technological  risk.  The  objectives  must  be  organized  in 
such  a  way  that  the  engineer  may  judge  alternative  solutions  against  all  the  objectives,  and 
perform  trade-off  analyses  where  necessary. 

Value  system  design  translates  CDM  values  into  a  hierarchy  of  objectives,  where 
objectives  flow  down  from  the  top  level  in  a  well-structured  maimer.  Each  bottom-level 
objective  has  a  corresponding  measure  of  effectiveness  (MOE),  by  which  the  performance 
of  that  objective  is  measured.  In  addition,  each  objective  is  weighted,  in  terms  of 
importance,  relative  to  the  other  objectives  at  the  same  level.  Based  on  the  performance 
of  each  objective,  and  the  priorities  of  those  objectives,  alternative  solutions  receive  a 
utility  score,  which  can  be  compared  to  the  scores  of  other  alternatives.  In  this  way,  the 
value  system  allows  the  engineer  to  analyze  trade-offs  between  competing  objectives. 
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Each  bottom-level  sub-objective  has  a  unique  measure  of  effectiveness.  The  ideal 
MOE  is  a  natural  scale  which  can  be  directly  measured  or  computed,  such  as  speed  in 
meters  per  second.  However,  the  true  MOE  is  often  difficult  and  impractical  to  obtain. 
This  is  especially  true  for  studies  which  occur  early  in  the  life-cycle  of  a  system,  where 
modeling  and  testing  is  limited.  In  this  case,  two  options  are  available  (Clemen,  1996:  79). 
The  first  is  to  use  a  proxy  measurement.  The  proxy  should  be  closely  related  to  the 
objective  under  consideration.  The  second  option  is  to  “construct  an  attribute  scale  for 
measuring  achievement  of  the  objective”  (Clemen:  79).  This  requires  the  definition  of 
levels  of  performance  for  the  objective,  with  levels  ranging  from  best  to  worst. 

Several  of  the  MOEs  for  this  study  are  actually  combinations  of  proxy 
measurements  and  attribute  scales.  All  attribute  scales  used  for  this  study  have  six  levels, 
from  zero  (worst)  to  five  (best).  It  was  felt  that  six  levels  provided  enough  detail  to  make 
intelligent  judgments. 

The  MOEs  for  each  bottom  level  objective  are  given  in  section  5.2.  The 
contributing  factors  that  aided  in  the  construction  of  attribute  scales  are  explained  in  Vol- 
II. 

Although  most  of  the  MOEs  are  constructed  attribute  scales,  fiiture  design  efforts 
for  this  program  must  convert  these  to  natural  scales  wherever  possible. 

It  should  be  noted  that  for  several  of  the  objectives,  the  evaluation  of  the 
performance  of  the  alternative  solutions  proved  to  be  challenging.  Members  of  the  team 
combined  their  knowledge  and  experience  to  rate  the  performance  of  such  objectives. 
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5.2  Objectives 

The  team  determined  that  the  overall  objective  of  this  study  is  to: 

“DEVELOP  THE  BEST  STANDARDIZED  BUS  FOR  A  SMALL  TACTICAL 
SATELLITE." 

It  is  important  to  understand  what  the  words  in  this  objective  mean  in  order  to  prevent  any 
misinterpretations  between  team  members,  advisors  and  the  chief  decision  maker.  The  key 
words  are  defined  below; 

1 .  STANDARDIZED:  The  most  important  idea  of  the  study.  All  other  objectives  must 
support  this.  The  idea  is  that  the  bus  will  support  many  different  mission  types. 

2.  THE  BEST:  Implies  an  open-minded  approach  to  developing  the  best  system,  free 
fi-om  the  bias  of  favored  technologies  and  approaches. 

3.  SMALI.:  The  satellite  must  be  compatible  with  a  light  weight  launch  vehicle,  such  as 
the  Pegasus  or  the  Lockheed  Martin  Launch  Vehicle. 

4.  TACTICAL:  The  project  statement  emphasizes  tactical  missions  and  a  short  life. 

The  set  of  objectives  used  for  this  study  is  intended  to  fully  capture  the  values  of 
the  CDM.  Thus,  all  of  the  objectives  discussed  below  were  used  to  guide  the 
development  of  subsystem  and  system-level  solutions.  Throughout  the  design  of  the 
overall  system,  many  trade-offs  were  performed  at  the  system  and  subsystem  levels,  in  an 
effort  to  form  a  reasonably  sized  solution  space  within  which  alternative  system  solutions 
could  be  evaluated. 
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The  top-level  objectives  are  shown  in  Figure  5-1.  The  following  sections  explain 


each  objective. 


I  Produce  Best  Standardized  Bus  Ck>ncept  | 


Figure  5-1:  Top-level  objectives 


5.2.1  Minimize  Cost 

The  cost  is  made  up  of  two  main  elements.  The  first  element  is  monetary  cost. 

The  performance  of  each  monetary  cost  objective  may  not  be  measured  in  actual  dollars; 
for  some  objectives  a  proxy  utility  scale  will  describe  the  cost.  For  others,  cost  estimating 
relationships  (CERs)  may  be  used  where  such  relationships  are  available.  CERs  yield  a 
cost  in  dollars,  but  all  such  costs  must  be  stated  for  the  same  year  (i.e.,  FY96  dollars). 

The  second  main  element  of  cost  is  time. 

There  are  9  bottom  level  objectives  and  MOEs  under  the  cost  objective. 

0-1.  Minimize  Time  to  Full  Rate  Production  (  MOE;  attribute  scale) 

•  Minimize  Monetary  Cost 

0-2.  Minimize  Research,  Development,  Test  and  Engineering  (RDT&E)  Cost  ( 
MOE;  Cost  estimating  relationship) 

0-3.  Minimize  Bus  Production  Cost  (  MOE;  Cost  estimating  relationship) 
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0-4.  Minimize  Retirement  Cost  (  MOE;  Attribute  scale) 

•  Minimize  Operations  Cost 

0-5.  Minimize  Cost  of  Telemetry,  Tracking,  and  Commanding 
(MOE:  Attribute  scale) 

•  Minimize  Cost  of  Pre-Launch  Operations 

0-6.  Minimize  Cost  of  Mission  Module  Integration  and  System 
Test  ( MOE:  Attribute  scale) 

0-7.  Minimize  Cost  of  Maintenance  ( MOE:  Attribute  scale) 
0-8.  Minimize  Cost  of  Storage,  Handling,  and  Transportation 
(MOE:  Attribute  scale) 

0-9.  Minimize  Cost  of  Launch  Integration  and  Test  ( MOE: 
Attribute  scale) 

5.2.2  Maximize  Tactical  Responsiveness 

Modsat  is  intended  for  tactical  applications,  as  has  been  stressed  by  the  CDM. 
Thus,  responsiveness  is  a  primary  objective.  Modsat  satellites  must  be  able  to  respond 
quickly  to  rapidly  generated  needs  and  mission  requirements.  One  major  driver  of 
responsiveness  is  the  availability  of  a  launch  vehicle;  however,  it  was  assumed  for  this 
study  that  launch  vehicles  are  continuously  available. 

The  bottom  level  objectives  are: 

0-10.  Minimize  Preparation  Time  to  Launch  (  MOE:  Attribute  scale) 

0-11.  Minimize  Data  Latency  ( MOE:  Attribute  scale) 

0-12.  Maximize  Capability  For  Tactical  Maneuvers  (  MOE:  Attribute  scale) 
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5.2.3  Maximize  Availability 


A  sound  system  design  for  Modsat  must  attempt  to  maximize  on-orbit  availability. 
The  bus  must  endure  both  natural  and  man-made  hazards.  Natural  hazards  are  considered 
under  rehability,  while  man-made  hazards  are  considered  under  survivability. 

0-13.  Maximize  Reliability  ( MOE;  Attribute  scale) 

0-14.  Maximize  Survivability  (  MOE:  Attribute  scale) 

5.2.4  Minimize  Program  Risk 

Program  risk  refers  to  the  potential  for  elements  of  the  program  to  fail  to  come 
together  as  planned.  Risk  can  be  assessed  in  the  areas  of  cost,  schedule,  and  performance. 
0-15.  Minimize  Cost  Risk  ( MOE:  Attribute  scale) 

0-16.  Minimize  Schedule  Risk  ( MOE:  Attribute  scale) 

0-17.  Minimize  Performance  Risk  ( MOE:  Attribute  scale) 

5.2.5  Maximize  Mission  Utility 

Mission  utility  refers  to  the  ability  of  Modsat  to  accommodate  a  range  of  different 
mission  modules.  In  other  words,  it  is  a  way  of  quantifying  how  well  the  bus  performs  its 
role  of  being  generic  and  standard.  The  larger  the  range  of  possible  missions,  the  higher 
the  mission  utility.  This  objective  was  difficult  to  construct,  since  it  is  hard  to  envision 
how  such  utility  can  be  measured.  It  was  decided  that  mission  utility  is  supported  by  the 
various  aspects  of  spacecraft  bus  performance,  such  as  pointing  accuracy  and  available 
power.  In  other  words,  if  more  performance  capability  is  built  into  the  bus,  more  mission 
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types  can  be  accommodated.  Thus,  several  performance  sub-objectives  were  adopted,  in 
addition  to  the  obvious  desire  to  maximize  the  available  weight  and  volume  for  the  mission 
module. 

0-18.  Maximize  Pointing  Accuracy  ( MOE:  Degrees  of  pointing  accuracy) 

0-19.  Maximize  Data  Storage  (MOE;  Attribute  scale) 

0-20.  Maximize  Average  Mission  Module  Power  (  MOE:  Watts  of  available  average 
power) 

0-21.  Maximize  Allowable  Mission  Module  Weight  (  MOE;  Kilograms  of  available 
weight) 

0-22.  Maximize  Adaptability  ( MOE;  Attribute  scale) 

0-23.  Maximize  Orbital  Accuracy  ( MOE:  Attribute  scale) 

0-24.  Maximize  Data  Down-link  Rate  (  MOE:  Mbytes/sec) 

0-25.  Maximize  Peak  Mission  Module  Power  (  MOE:  Watts  of  available  peak  power) 
0-26.  Maximize  Allowable  Mission  Module  Volume(  MOE:  cm^  of  available  volume) 
0-27.  Minimize  Thermal  Transfer  (  MOE;  Attribute  scale) 

5.3  Utility  Functions 

In  order  to  provide  overall  utility  scores  for  each  competing  system  solution,  all 
MOEs  must  be  converted  to  a  common  utility  scale.  The  team  chose  a  scale  from  zero  to 
one  for  convenience,  but  the  endpoints  of  the  scale  could  be  any  numbers.  The  translation 
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from  MOE  to  utility  for  a  given  objective  is  referred  to  as  the  utility  function  of  that 
objective.  A  utility  function  is  essentially  a  model  that  represents  the  preferences  of  the 
CDM  for  an  objective  (Clemen;  473).  Feedback  from  the  CDM  enables  the  analyst  to 
determine  how  much  utility  to  assign  a  given  level  of  performance. 

Ideally,  each  objective  would  have  a  unique  utility  function  that  reflects  the  risk 
attitude  of  the  CDM.  However,  in  the  absence  of  participation  from  the  CDM,  the  team 
took  a  generalized  approach.  The  validity  of  the  results  of  this  study  could  be  improved 
with  feedback  from  the  CDM  with  regard  to  utility  fiinctions. 

5.4  Priority  Weighting  of  The  Objectives 

The  objectives  on  the  same  level  in  the  hierarchy  were  assigned  priority  weights,  as 
shown  in  Figure  5-2.  These  weights  were  determined  based  on  the  results  of  a  preference 
chart  survey.  This  survey  was  completed  by  the  CDM,  members  of  the  team,  and  other 
subject  matter  experts,  with  feedback  from  the  CDM  being  more  heavily  weighted.  The 
actual  survey  is  attached  as  Appendix  A. 
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Produce  Best  Standardized  Bus  Concept 
1.0000 


Figure  5-2:  Phase  two  objective  hierarchy 
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From  Figure  5-2,  it  is  clear  which  objectives  are  more  important  than  others  in  the 
current  value  system.  It  should  be  noted  that  this  set  of  weights  is  a  reflection  of  personal 
opinions,  solicited  at  a  certain  time  and  under  a  given  set  of  technological,  political,  and 
economic  conditions.  Major  changes  in  any  of  these  areas  could  cause  the  relative 
priorities  to  change.  This  potential  for  change  does  not  present  a  significant  problem, 
since  the  overall  scoring  function  (see  section  5.5)  can  easily  be  re-calculated  with  new 
weights.  In  fact,  a  sensitivity  analysis  was  performed  on  the  alternative  solutions  by 
varying  the  weights  of  each  of  the  top-level  objectives. 

A  comparison  of  the  priorities  of  the  top-level  objectives  is  shown  in  Figure  5-3. 
Tactical  responsiveness  is  the  highest-rated  objective,  while  mission  utility  has  the  second 
highest  priority.  It  is  interesting  to  note  that  the  cost  objective  received  the  lowest  rating, 
as  opposed  to  its  prominence  in  most  system  studies. 
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Objectives 


Figure  5-3:  Top-level  objective  weights 
5.5  Scoring  Function 

The  utility  values  and  objective  weights  must  be  combined  to  form  an  overall 
utility  function.  This  function  yields  an  overall  utihty  score  for  a  given  alternative 
solution,  based  on  its  performance  of  each  objective  and  the  relative  importance  of  those 
objectives.  Alternative  system  solutions  can  be  compared  by  their  overall  utility  scores. 

Since  this  study  was  intended  to  produce  concept-exploration  design 
characteristics,  and  not  detailed  design  recommendations,  the  team  decided  to  avoid 
modeling  the  interaction  among  the  objective  attributes. 
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5.6  Flexibility  of  the  Value  System 


Since  the  value  system  drives  all  design  eflforts,  changes  in  any  of  the  elements  of 
the  value  system  can  lead  to  different  results.  The  objectives,  weights,  and  utility 
functions  used  for  this  study  could  be  modified  upon  further  engineering  efforts.  It  was 
not  the  intent  of  the  team  to  create  a  rigid,  unchanging  value  structure,  but  rather  to  create 
a  robust  fi-amework  within  which  intelligent  decisions  could  be  made.  Now  that  the 
framework  exists,  it  can  be  modified  according  to  the  changing  desires  of  the  CDM  and 
the  analysts  who  conduct  further  research  on  this  topic. 
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6.  Tradeoffs 


6.1  System  Level 

Many  important  tradeoffs  were  analyzed  at  the  system  and  subsystem  level,  and 
several  critical  design  decisions  were  made.  The  purpose  of  this  section  of  the  report  is  to 
document  these  tradeoffs  and  decisions.  Throughout  the  system  study,  the  team  has 
encountered  many  variables  and  options.  Some  of  these  have  remained  as  variables,  to  be 
specified  as  elements  of  alternative  system  solutions  for  judgment  against  the  value  system 
criteria.  However,  many  design  decisions  were  made  during  this  study,  in  order  to  narrow 
the  solution  space  to  a  reasonable  set  of  alternatives.  Thus,  the  Modsat  bus  concept 
gained  its  shape  throughout  the  study,  as  key  decisions  have  built  on  each  other.  These 
decisions  were  made  after  performing  tradeoffs  between  the  alternatives,  judging  each 
against  the  Modsat  objectives  and  constraints. 

Much  work  was  done  at  the  subsystem  level,  and  this  is  documented  in  section  4.5. 
This  section  discusses  the  system  level  tradeoflfs. 

6.1.1  One  Satellite  Per  Launch  Vehicle 

Rather  than  attempt  to  design  very  small  satellite  buses  for  a  multiple-payload 
launch  package,  the  team  chose  to  focus  on  one  vehicle  that  will  fill  the  payload  bay  of  the 
chosen  launch  vehicle  (LV).  A  key  objective  of  the  study  is  to  allow  for  as  much  mission 
module  capability  as  possible  per  bus.  It  would  be  inconsistent  with  this  objective  to  force 
mission  module  designers  to  integrate  with  a  microsat,  or  to  make  them  spread  their 
mission  capability  over  a  multiple-satellite  configuration. 
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6.1.2  Launch  Vehicle 


The  team  originally  chose  the  Pegasus  XL,  from  Orbital  Sciences  Corporation 
(OSC).  This  LV  is  common  for  small  low  earth  orbit  (LEO)  satellites.  It  is  attractive  for 
several  reasons,  among  them  being  the  ability  to  respond  rapidly  to  mission  needs  and  the 
flexibility  of  launch  integration  and  location. 

6.1.3  Basic  Spacecraft  Configuration 

Modsat  requires  three  axes  of  pointing  control,  since  it  has  articulated  solar  arrays 

(see  section  6.5.6)  and  must  accommodate  nadir  pointing  mission  modules.  According  to 

aerospace  consultant  Emery  Reeves, 

“The  spacecraft  configuration  must  provide  two  axes  of  control  for  each 
item  that  is  to  be  pointed.  The  spacecraft  body  has  three  axes  so  the  body 
alone  can  satisfy  one  pointing  requirement;  for  instance,  one  body  axis  (i.e., 
the  yaw  axis)  can  be  pointed  toward  nadir  by  control  about  the  other  two 
axes  (roll  and  pitch).  It  two  items  are  to  be  pointed,  then  the  spacecraft 
must  be  configured  vrith  at  least  one  articulated  joint  between  the  two 
items.  For  illustration,  a  body  mounted  antenna  can  be  pointed  nadir  by 
controlling  two  axes  of  body  attitude.  A  solar  array  can  then 
simultaneously  be  pointed  toward  the  Sun  by  using  the  third  body  axis  and 
providing  a  single  solar  array  drive  to  control  the  solar  array  attitude 
relative  to  the  body. .  .3-axis-controlled  spacecraft  generally  use  articulated 
panels”  (Reeves,  1992:297). 

Although  two-axis  systems  are  usually  cheaper,  lighter,  and  less  complex  than 
three-axis  systems  (Reeves,  1992:305),  it  was  determined  that  the  pointing  requirements 
of  both  the  solar  arrays  and  the  nadir  pointing  mission  modules  mandate  the  use  of  three- 
axis  control. 
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6.1.4  Data  Delivery  Architecture 


The  users  in  the  field  would  like  to  have  their  mission  data  as  rapidly  as 
possible.  By  requirement,  Modsat  must  have  S-band  SGLS  (space  to  ground-link 
subsystem)  antennas  which  are  compatible  with  the  AFSCN.  The  SGLS  link  is  limited  to 
a  maximum  data  rate  of  1 .024  Mbits/sec.  Any  tactical,  warfighting  satellite  would  benefit 
greatly  from  having  its  own  high  data  rate  downlink  antenna(s),  in  addition  to  the  SGLS 
antennas.  Thus,  the  design  team  acknowledged  that  almost  all  Modsat  satellites  would 
require  a  high  data  rate  antenna  in  addition  to  the  required  SGLS  antennas.  It  was 
decided  by  the  team  to  avoid  selecting  and  integrating  a  particular  type  of  antenna. 

Rather,  the  mission  planners  will  have  the  flexibility  to  choose  antennas  that  suit  their 
needs.  Thus,  all  Modsat  bus  designs  accounted  for  the  placement  of  a  high  data  rate 
package,  whether  in  the  bus  itself  (as  a  standardized  add-on)  or  as  part  of  the  mission 
module. 

6.1.5  Adaptability  and  Modularity 

As  mentioned  in  the  Problem  Definition  section,  the  CDM  desires  Modsat  to  have 
a  flexible,  adaptable  design,  such  that  additional  capability  can  inserted,  or  excess 
capability  can  be  removed,  depending  on  the  needs  of  each  mission  module.  A  modular 
approach  will  be  used,  whereby  all  busses  are  manufactured  with  all  foreseeable 
component  options  attached  via  removable  interfaces.  Of  course,  center  of  mass  and 
attitude  control  constraints  may  preclude  the  removal  of  some  excess  components, 
depending  on  the  characteristics  of  the  mission  module  in  question. 
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6.1.6  Maximum  Capability 


The  Modsat  bus  must  accommodate  a  wide  variety  of  mission  modules,  and  must 
therefore  cater  to  the  most  demanding  customers.  This  implies  that  there  will  be  excess 
capability  on  many  missions.  Some  of  this  may  be  mitigated  by  the  modular  architecture 
discussed  above,  but  certainly  not  all  excess  capability  can  be  removed.  Some  built-in 
excess  is  unavoidable  with  a  mandated,  standardized  interface. 

6.1.7  On-Board  Propulsion 

Magnetic  torquers  are  often  used  in  place  of  the  bulkier  propellant-thruster 
configurations  to  reduce  spacecraft  momentum.  However,  magnetic  torquers  cannot 
perform  AV  maneuvers  (Everett,  1996).  In  section  6.4,  it  will  be  shown  that  Modsat 
requires  AV  capability  to  maintain  its  altitude  at  LEO.  Moreover,  thrusters  are  required 
to  perform  tactical  repositioning  AV  maneuvers,  which  may  very  well  be  required  as  part 
of  Modsat’s  tactical  mission  profile  (see  Problem  Definition). 

6.1.8  Data  Processing 

Most  space  sensor  applications  require  some  degree  of  processing  of  the  mission 
data,  prior  to  its  transmission  to  the  ground.  In  any  given  custom-built  satellite,  it  is 
possible  for  such  data  to  be  handled  by  the  main  spacecraft  processor,  along  with  all  of  its 
other  processing  functions.  However,  each  mission  type  has  its  own  very  unique 
processing  requirements,  and  it  would  be  impossible  to  satisfy  all  with  one  processor.  In 
fact,  many  instruments  have  their  own  mini-computers.  Thus,  the  team  decided  that 
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mission  data  processing  must  be  performed  by  the  mission  module.  However,  data 
storage  will  be  available  in  the  bus  processor,  as  stated  in  the  requirements. 

6.1.9  The  Bus-To-Mission  Module  Interface 

Another  key  part  of  this  study  is  the  specification  of  a  standardized  interface 
between  the  bus  and  all  mission  modules.  This  very  issue  has  been  addressed  by  the 
Aerospace  Corporation,  and  the  results  are  documented  in  “An  Approach  To  Rapid 
Payload  Integration:  The  Spacecraft-To-Payload  Interface  Guideline  (SPIG),  Version  1” 
(Aerospace  Corporation,  1996).  According  to  this  document,  “the  SPIG  is  intended  to 
serve  as  a  core  building  block  on  which  the  payload-to-spacecraft  interface  can  be 
designed.” 

In  the  production  of  the  SPIG,  much  systems  engineering  work  has  been 
accomplished  to  suggest  an  optimum  standardized  interface.  The  team  decided  to  use  the 
SPIG  interface  in  lieu  of  designing  their  own  interface. 

6.2  Reliability  Analysis 

This  study  was  undertaken  to  determine,  at  a  minimum,  an  optimal  starting  point 
for  the  cost  vs.  reliability  tradeoff.  Fault  tolerance  via  three  different  subsystem 
redundancy  levels  (single-string,  double-string,  triple-string),  and  fault  avoidance  via  three 
different  component  quality  classes  (commercial-grade.  Class  B,  Class  S)  were  compared. 
Educated  assumptions  were  made  regarding  the  relative  costs  of  commercial.  Class  B,  and 
Class  S  components.  The  cost  assumptions  were  changed  twice  to  determine  the  effect  on 
the  optimum  cost/reliability  option.  A  baseline  cost  of  $30M,  calculated  fi'om  the  Modsat 
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cost  model,  was  used  in  the  study.  The  failure  data  used  was  extracted  from  a  study  of 
over  300  spacecraft  failures  from  the  early  1960s  to  1984,  dividing  failure  rates  by  an 
"improvement  factor"  to  account  for  advances  in  technology. 

The  study  showed  that  the  optimum  point  to  begin  a  detailed  cost  vs.  reliability 
trade  study  was  with  a  Class  B,  single-string  spacecraft.  Varying  the  cost  assumption  did 
not  significantly  affect  the  result.  Double  and  triple-string  spacecraft  with  commercial 
parts  also  fared  well,  but  when  the  weight  penalty  associated  with  redundancy  was 
considered.  Class  B/single-string  stands  apart.  Optimahty  was  determined  by  fitting  a 
curve  to  the  data  and  looking  for  the  point(s)  closest  to  the  "knee"  of  the  curve.  An  even 
more  optimal  starting  point  might  be  achieved  by  designing  a  spacecraft  that  is  Class 
B/Class  S  and/or  redundant  where  warranted  (e.g.  the  Telemetry,  Tracking,  and 
Commanding  subsystem).  The  availability  of  Class  S  and  B  components  in  an  era  of 
decreased  government  space  and  defense-related  cuts,  as  well  as  the  rapid  growth  in  the 
quality  of  commercial-oriented  components,  was  not  quantified  in  this  study. 


6.3  Launch  Vehicle  Considerations 

The  sponsor’s  guidance  required  the  satellite  bus  to  be  within  the  Pegasus  and 
Lockheed  Martin  Launch  Vehicle  (LMLV)  weight  class  (Rooney,  1996).  Orbital  Science 
Corporation’s  Pegasus  XL  was  chosen  as  the  baseline  LV,  based  on  its  success  and 
experience.  The  air-launched  nature  of  the  Pegasus  offers  a  tactical  advantage  over  other 
conventional  ground-based  LVs.  The  capability  of  being  rapidly  deployed  and  launched 
into  any  inclined  Low  Earth  Orbits  (LEO)  from  any  latitude  and  longitude  is  another 
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distinct  advantage  of  the  Pegasus.  More  specifically,  the  Pegasus  XL  was  chosen  over 
the  standard  Pegasus  vehicle  because  the  XL  version  offers  more  mass-to-orbit 
performance. 

6.3.1  Pegasus  XL 

The  Pegasus  XL  is  a  winged,  three-stage,  solid  rocket  booster  that  weighs 
approximately  22,680  kg  (50,000  Ibm)  and  measures  16.9  m  (55.4  ft;)  in  length  and  1.27 
m  (50  in)  in  diameter.  The  rocket  is  lifted  by  a  carrier  aircraft,  usually  a  Lockheed  L- 
101 1,  to  a  level  flight  condition  about  1 1,580  m  (38.000  ft)  and  Mach  0.79  before  it  is 
released  for  launch  (Orbital  Science  Corporation,  1993:2-1). 

There  are  two  major  Pegasus  XL  features  that  impose  restrictions  on  potential 
satellite  bus  designs.  One  is  the  Pegasus  XL  mass-to-orbit  performance  capability;  the 
other  is  the  booster’s  payload  fairing  dimensions. 

6.3.2  Mass-to-Orbit  Performance 

An  important  characteristic  of  any  launch  vehicle  is  the  amount  of  mass  it  can 
place  into  orbit.  The  mass  that  the  Pegasus  XL  can  deliver  depends  on  the  altitude  and 
inclination  of  the  desired  orbit,  and  whether  the  booster  uses  an  optional  Hydrazine 
Auxiliary  Propulsion  System  (HAPS,  explained  below).  The  mass-to-orbit  performance 
capability  for  the  Pegasus  XL  is  provided  in  Figure  6-4. 
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Figure  6-4:  Pegasus  XL  Performance  Capability 


6.3.3  Payload  Fairing 

Pegasus  XL  offers  two  payload  interfaces;  a  38  inch  diameter  interface  plate  and  a 
23  inch  diameter  interface  plate.  Both  of  these  interface  plates  can  be  used  with  or 
without  HAPS.  Figure  6-5  shows  the  payload  fairing  with  the  38  inch  interface.  If  this 
configuration  is  used  with  the  optional  HAPS,  the  spacecraft  design  will  lose  14.65  inches 
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from  the  available  84.22  inch  height.  Figure  6-6  depicts  the  23  inch  configuration  without 
HAPS.  When  the  HAPS  is  used  with  the  23  inch  interface,  4.2  inches  are  deducted  from 
the  70.57  inch  height. 


Source:  OSC,  1993:5-3 


Figure  6-5:  Payload  Fairing  with  38  inch  Interface 


57 


Source;  OSC,  1993:5-4 

Figure  6-6;  Payload  Fairing  with  23  inch  Interface 


6.3.4  Hydrazine  Auxiliary  Propulsion  System 

The  purpose  of  the  HAPS  is  twofold.  It  improves  orbital  injection  accuracy  and 
increases  mass-to-orbit  capability  for  satellites  placed  into  altitudes  greater  than 
approximately  600  kilometers.  The  inclusion  of  a  HAPS  adds  weight  to  the  LV  and 
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mandates  additional  restrictions  on  the  height,  mass  and  volume  of  the  spacecraft,  in  a 
trade  for  added  accuracy  and/or  higher  orbit  insertion.  It  was  decided  that  the  vast 
majority,  if  not  all,  of  the  Modsat  missions  would  not  require  orbital  altitudes  above  600 
kilometers.  Additionally,  orbital  insertion  accuracy  is  mission  specific  and  depends  on 
mass,  targeted  orbit,  and  the  particular  guidance  strategy  adopted  for  the  mission  (OSC, 
1993:3-5).  Thus,  the  team  decided  to  exclude  the  HAPS  configuration  from 
consideration. 

6.3.5  Other  Considerations 

Many  other  characteristics  of  the  Pegasus  XL  influenced  and  constrained  the 
design  effort,  including: 

•  Spacecraft  center  of  mass  location  constraints 

•  Spacecraft  stiffiiess/vibrational  frequency  constraints 

•  Spacecraft  mass  limitations  due  to  critical  shear  stress  at  the  LV  interface 

•  Axial  and  lateral  loads  during  launch 

To  ensure  that  the  design  alternatives  do  not  violate  the  Pegasus  XL  constraints, 
launch  vehicle  compatibility  testing  was  incorporated  into  the  Modsat  model  through  3-D 
surface  rendering  visualization  (see  Volume  HI). 
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6.4  Baseline  Orbit  and  Allowable  Launch  Mass 


6.4.1  Baseline  Orbit-Type 

Section  6.3  demonstrated  that  sun-synchronous  orbits  are  the  most  weight 
restrictive  orbits  for  a  launch  vehicle.  Many  Modsat  missions  may  require  a  sun- 
synchronous  orbit.  Therefore,  the  bus  should  be  light  enough  to  allow  for  such  missions. 
But  in  order  to  establish  a  baseline  launch  mass,  a  baseline  orbital  altitude  must  be 
determined.  This  altitude  will  not  be  dictated  to  mission  planners;  in  reality,  they  have  the 
latitude  to  select  an  appropriate  orbit,  provided  their  spacecraft  meet  the  launch  mass 
constraint. 

Nevertheless,  the  team  needed  a  maximum  mass  limit  for  design  purposes.  Recall 
from  Value  System  Design  that  one  of  the  measures  of  effectiveness  for  this  study  is 
allowable  mission  module  mass.  For  the  baseline  orbital  altitude,  this  mass  is  the  allowable 
launch  mass  less  the  mass  of  the  bus.  The  challenge  was  to  find  the  optimum  sun- 
synchronous  orbit  for  design,  and  therefore,  the  spacecraft  mass  limit.  The  optimum  orbit 
is  defined  as  that  which  maximizes  the  allowable  launch  mass. 

6.4.2  Mass  to  Altitude  Tradeoff 

The  mass-to-orbit  performance  of  a  launch  vehicle  decreases  as  the  orbital  altitude 
increases.  Thus,  lower  altitudes  are  desirable  for  large  payloads.  However,  as  the  orbital 
altitude  decreases,  the  requirement  for  AV  (thrust)  to  maintain  altitude  increases  due  to 
increased  atmospheric  drag. 
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Since  AV  is  provided  through  the  use  of  propellant,  the  amount  of  propellant  on¬ 
board  the  spacecraft  is  proportional  the  AV  required  to  maintain  altitude.  Thus,  this 
analysis  seeks  to  maximize  the  allowable  launch  mass  for  a  sun-synchronous  orbit,  less  the 
mass  of  the  propellant  reserved  for  altitude  maintenance.  Analysis  shows  that  this  mass 
increases  with  altitude,  until  350  km.  Beyond  this,  the  AV  requirement  decreases  but  the 
allowable  launch  mass  decreases  dramatically.  Thus,  the  baseline  design  altitude  was 
chosen  to  be  350  km.  At  this  altitude,  approximately  308  kg  can  be  launched  into  sun- 
synchronous  orbit. 

6.5  Subsystem  Tradeoffs 

Tradeoff  analyses  were  performed  at  the  subsystem  level,  in  order  to  further 
narrow  the  solution  space.  The  subsystems  of  Modsat  are  described  below: 
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Table  6-1:  Spacecraft  Subsystems 


Subsystem 

Principal  Functions 

Other  Names 

Attitude  Determination  and 

Provides  determination  and 

Attitude  Control  System 

Control  System  (ADCS) 

control  of  attitude  and  orbit 
position,  plus  pointing  of 
spacecraft  and  appendages 

(ACS),  Guidance, 

Navigation  and  Control 
(GN&C)  System,  Control 
System 

Propulsion 

Provides  thrust  to  adjust 
orbit  and  attitude,  and  to 
manage  angular  momentum 

Reaction  Control  System 
(RCS) 

Structures  and  Mechanisms 

Provides  support  structure, 
booster  adapter,  and  moving 
parts 

Structure  Subsystem 

Thermal  Control 

Maintains  equipment  within 
allowed  temperature  ranges 

Environmental  Control 

System 

Telemetry,  Tracking  and 
Command  (TT&C) 

Communicates  with  ground 
and  other  spacecraft; 
spacecraft  tracking 

Communication  (Comm) 

Electrical  Power  System 
(EPS) 

Generates,  stores,  regulates, 
and  distributes  electric 
power 

Power 

Source:  Reeves,  1992:287 

6.5.1  Attitude  Determination  and  Control 

The  purpose  of  the  Attitude  Determination  and  Control  System  (ADCS)  is  to  (1) 
stabilize  the  spacecraft  against  both  external  and  internal  torques  that  would  disturb  its 
desired  orientation,  and  (2)  maneuver  and  point  the  spacecraft  in  response  to  commands. 
An  ADCS  must  meet  several  stability  and  agility  requirements,  including  pointing  accuracy 
and  satellite  slewing  rate.  An  ADCS  must  operate  in  several  control  modes,  each  of  which 
is  employed  during  the  various  phases  of  the  satellite's  mission,  each  having  different 
requirements.  Since  normal  operations  and  satellite  slewing  control  modes  are  the  most 
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common,  they  tend  to  be  the  requirements  drivers.  Defining  the  various  control  modes  is 
the  first  step  in  designing  an  ADCS. 

The  second  step  is  selecting  the  particular  type  of  the  attitude  control  method. 
Control  methods  range  from  passive  to  active,  spinning  to  three-axis  stabilized, 
momentum-biased  via  constantly  spinning  rotors  internal  to  the  spacecraft,  to  zero- 
momentum  biased  (no  spinning  rotors).  Modsat  employs  a  three-axis  stabilized  system, 
which  offers  the  greatest  amount  of  stability. 

The  next  step  in  ADCS  design  is  to  quantify  the  disturbing  torques  the  spacecraft 
will  be  subject  to.  Internal  torques  can  be  controlled  through  careful  design.  External 
torques  must  be  quantified  and  compensated  for.  External  torques  generally  have  four 
sources;  gravity-gradients,  magnetic  effects  due  to  the  Earth's  magnetic  field,  solar 
radiation,  and  aerodynamics.  At  the  low  altitudes  Modsat  will  operate  in,  disturbances  due 
to  aerodynamics  outweigh  the  others  by  two  to  three  orders  of  magnitude.  Thus  Modsat's 
ADCS  is  designed  primarily  against  aerodynamics-based  disturbances. 

Next,  ADCS  hardware  must  be  selected.  This  includes  attitude  sensors  (Sun 
sensors.  Earth  sensors,  star  sensors,  inertial  measurement  units,  magnetometers),  and 
actuators  (reaction  wheels,  momentum  wheels,  control-moment  gyroscopes,  magnetic 
torquers,  thrusters).  The  sensor  suite  chosen  for  Modsat  was  an  Earth  sensor,  a  star 
sensor,  and  an  IMU.  This  combination  best  satisfied  the  requirements  of  the  different 
control  modes.  The  actuators  selected  were  thrusters  and  reaction  wheels,  which  were 
best  suited  for  Modsat's  requirements  and  operating  environment. 
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The  final  step  in  ADCS  design  is  the  design  of  the  control  algorithms  that  tie  the 
sensors,  actuators,  and  user-commands  together.  Although  detailed  control-law 
development  requires  a  detailed  knowledge  of  the  satellite's  predicted  dynamic  behavior 
(which  itself  requires  detailed  knowledge  of  the  satellite's  overall  design),  the  designer  can 
estimate  the  amount  of  control  authority  needed  by  considering  the  estimated  worst-case 
disturbance  together  with  the  spacecraft's  pointing  accuracy  and  stability  requirements. 


6.5.2  Propulsion 

The  team  did  not  set  out  to  design  new  concepts  in  spacecraft;  propulsion,  since  a 
major  emphasis  has  been  placed  on  the  use  of  competitively  priced,  proven  technology. 
Instead,  the  design  effort  was  limited  to  making  use  of  currently  available,  off-the-shelf 
technology. 

The  Modsat  propulsion  subsystem  performs  the  following  functions; 

•  Orbital  corrections. 

•  Tactical  re-deployment. 

•  Acquisition  of  Sun,  Earth,  or  star. 

•  On-orbit  back-up  mode  control  with  3-axis  stabilization. 

•  Momentum  management. 

•  3 -axis  control  during  AV. 
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6.5.2. 1  Propulsion  Options  For  Standard  Satellite  Bus  Alternatives 


Propulsion  subsystem  options  for  Modsat  were  modeled  and  chosen  with  the  aid 
of  the  Modsat  computer  model.  The  primary  alterables  for  the  propulsion  subsystem  are 
shown  in  Table  6-2.  The  design  and  placement  of  the  Modsat  propulsion  subsystem  is 
constrained  primarily  by  the  volume  and  weight  limitations  of  the  Pegasus  Launch  Vehicle. 


Table  6-2:  Propulsion  alterables 


Alterable  Elements 

Possible  Options 

Propulsion  Type 

Liquid  mono-propellant 

Liquid  bi-propellant 

Pressure  System 

Blow-down 

Regulated 

Propellant  type 

Many 

Shape  of  Tanks 

Spherical 

Cylindrical 

6.5.2.2  Propulsion  System  Decisions 

The  following  decisions  were  made  regarding  the  elements  and  configuration  of 

the  propulsion  subsystem. 

1.  The  entire  propulsion  subsystem  should  reside  on  the  bottom  level  of  the  satellite  bus. 

•  Launch  vehicle  considerations  deem  that  the  center  of  gravity  of  the  spacecraft  be  as 
low  as  possible  on  the  LV/spacecraft  z-axis. 

•  Since  the  specific  mission  modules  that  will  be  flown  on  Modsat  are  unknown,  it  is 
wise  to  keep  any  thrusters  well  below  the  bus-to-mission  module  interface. 

•  The  effects  of  thruster  exhaust  plume  and  other  possible  contamination  from  the 
propulsion  system  are  reduced  by  locating  it  on  a  designated  bottom  plate. 
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•  The  propulsion  subsystem  does  not  fit  in  well  with  the  modular  nature  of  the  bus,  with 
its  removable  components  and  structural  assemblies.  It  would  be  extremely  difficult  to 
locate  any  of  the  big  components  and  systems  anywhere  other  than  on  a  fixed  plate  at 
the  bottom  of  the  bus. 

•  The  weight  of  pipes,  vanes,  valves,  and  the  other  propulsion  plumbing  equipment  is 
reduced  by  consolidating  the  whole  subsystem  in  one  location. 

2.  The  propellant  tanks  should  have  a  cylindrical  shape.  Cylindrical  tanks  maximize  the 
use  of  the  area  on  the  bottom  plate,  and  leave  more  volume  to  the  other  parts  and 
pieces. 

3.  The  mono-propellant  configuration  was  chosen  as  the  Modsat  standard. 

•  Simplicity,  cost,  and  reliability  advantages  over  the  bi-propellant  configuration. 

•  No  significant  difference  in  required  tank  volume  between  mono  and  bi-propellant 
configurations. 

4.  The  pressure  feed  system  should  be  a  blow-down  system. 

•  Modsat  does  not  require  the  capability  for  high-level,  long-duration  thrust.  A  low- 
thrust,  small  propulsion  system  is  adequate. 

•  Since  blow-down  systems  do  not  need  regulators  (and  sometimes  filters),  they  are 
simple  and  reliable  (Sutton,  1992:326). 

5.  Propellant:  hydrazine 

6.  Storage  system:  positive  expulsion 

7.  Commercial  off-the-shelf  thrusters  will  be  used. 
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Thus,  all  of  the  major  system  alternatives  for  this  study  were  designed  with  a 
mono-propellant  (24%HN  and  76%  N2H4  blend),  blow-down  pressure  fed  system  with 
cyhndrical  tanks. 


6.5.2.3  Propulsion  Alternatives 

After  making  the  design  decisions  discussed  above,  the  remaining  propulsion 
alterable  is  the  amount  of  propellant,  which  dictates  the  size  of  the  cylindrical  tanks. 

Although  the  mission  requirements  are  uncertain,  the  idea  behind  the  propellant 
alterable  was  to  provide  different  amounts  of  AV  capability.  This  capability  must  be 
divided  among  the  spacecraft  AV  budget,  which  accounts  for  tactical  maneuver  capability, 
mission  lifetime,  retirement,  and  orbital  accuracy.  For  a  given  amount  of  propellant,  this 
budget  must  be  managed  by  the  user  of  Modsat. 

The  amount  of  AV  required  to  maintain  the  baseline  orbital  altitude  or  350  km  is 
62.2  m/s  per  year.  At  this  altitude,  the  amount  of  A  V  required  to  make  a  one  degree 
plane  change  is  134.3  m/s  (Sackheim  and  others,  1992:  back  cover).  It  was  assumed  that 
momentum  management  will  require  35-50  m/s  of  AV  per  year.  The  chosen  propulsion 
alternatives  for  this  study  are  shown  in  Table  6-3. 


Table  6-3;  Propulsion  system  alternatives 


Alternative 

Altitude  Keeping 
(m/s) 

Momentum 

Dumping 

(m/s) 

Inclination  Change 
(m/s)  /  Degree 

Total  A  V 
(m/s) 

1 

62.2 

37.80 

-  /  0 

100 

2 

62.2 

36.35 

201.45  /  1.5 

300 

3 

62.2 

52.05 

335.75  /2.5 

450 
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Although  the  placement  of  thrusters  was  fixed,  for  each  alternative  the  propellant 
tanks  are  located  as  near  as  possible  to  the  center,  in  order  to  minimize  the  effect  of 
diminishing  propellant. 


Figure  6-7:  The  propulsion  system 
6.5.3  Structures  and  Mechanisms 

The  foundation  of  a  spacecraft  is  its  structures  and  mechanisms  subsystem. 
Structures  provides  the  fi'amework  for  mounting  the  mission  module  and  other 
subsystems;  it  must  also  connect  to  the  launch  vehicle.  “Structures  must  [also]  endure 
environments  fi-om  manufacture  to  the  end  of  the  mission”  (Doukas  and  others, 
1992:430).  As  with  all  satellite  structure  designs,  the  designer  must  review  and  adhere  to 
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the  mission  requirements.  In  this  study  the  mission  requirement  was  to  develop  a  low 
cost,  “launch  on  need”  tactical  satellite  bus  capable  of  supporting  various  mission  modules 
while  launching  off  a  Pegasus  class  booster. 

In  support  of  a  low-cost  design,  graphite  and  composite  materials  were  not 
considered.  Although  graphite-epoxy  composites  provide  “...extremely  high  stiffhess-to- 
weight  ratios...” ,  they  are  costly  and  “...often  require  a  long,  expensive  development 
program  to  establish  manufacturing  processes”  (Doukas  and  others,  1992:435-441). 
Because  the  use  of  composites  increases  the  complexity  of  the  structure  and  drives  up 
construction  costs,  the  use  of  other  metalUc  alloys,  such  as  aluminum,  is  more  desirable. 
According  to  Doukas,  et  al,  “Aluminum  is  relatively  hght-weight,  strong,  readily  available, 
easy  to  machine,  and  low  in  raw  material  cost”  (Doukas  and  others,  1992:435-441). 
Therefore,  only  aluminum  alloys  were  considered  for  the  main  structure  of  Modsat. 

“Launch-on-need”  implies  the  ability  to  launch  within  a  few  days,  as  opposed  to 
several  months,  as  with  current  launch  schedules.  Since  the  satellite  bus  must  be  able  to 
support  multiple  mission  modules,  modular  design  will  to  be  the  most  viable  answer  to  a 
quick  response  launch.  To  further  satisfy  the  “launch-on-need”  requirement,  the  Modsat 
satellite  bus  allows  for  quick  mission  module  and  launch  vehicle  integration,  easing  the 
removal,  replacement,  and  addition  of  the  mission  module  and  internal  subassembly 
components. 

Since  the  Pegasus  XL  is  Modsat’s  primary  launch  vehicle,  the  team  first  concentrated 
its  efforts  on  ensuring  the  satellite  bus  and  mission  module  would  fit  within  the  Pegasus 
payload  bay. 
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The  next  consideration  in  selecting  a  satellite  structure  was  to  select  a  geometric  shape 


that  best  utilizes  the  payload  bay’s  volume  and  maximizes  solar  access  (see  Figure  6-8). 


Figure  6-8:  Structure  Shapes 

Except  for  the  sphere,  the  geometric  shapes  are  of  similar  construction,  differing  only 
in  the  number  of  sides,  as  depicted  in  Figure  6-9.  One  can  see  how  increasing  the  number 
of  sides  utilizes  more  volume;  however,  there  is  a  diminishing  return  to  increasing  the 
number  of  sides. 


Figure  6-9:  Geometric  Shapes  with  Similar  Properties 

Although  it  appears  that  a  cylindrical  bus  is  the  best  geometric  shape,  the  increased 

weight,  limited  access  to  subcomponents,  and  restricted  solar  wing  placement  in  the 
stowed  configuration  make  it  a  less  desirable  choice.  Incidentally,  Leritz  and  Palmer,  in 
considering  a  geometric  shape  for  their  satellite  design  example,  selected  the  cylinder  and 
hexagon  because  they  “distribute  loads  more  uniformly”  (Leritz  and  Palmer,  1995:490). 
From  volume,  surface  area,  and  loading  considerations,  it  seems  likely  that  the  best 
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Modsat  structural  design  is  a  “polysat,"  an  n-sided  polygon.  By  varying  the  number  sides, 
the  best  Modsat  design  can  be  found.  Therefore,  the  “polysat”  design  became  the  main 
focus  of  structural  modeling. 

Other  considerations  in  the  design  of  a  satellite  bus  are  the  accessibility  of  internal 
subcomponents  and  the  ease  of  mating  the  mission  module  to  it.  Although  it  is  possible  to 
space  out  structural  members  farther  apart  for  cylindrical  and  spherical  bus  designs,  the 
number  of  members  still  exceeds  that  of  the  “polysat”  designs.  Also,  internal  component 
accessibility  from  the  side  is  more  impeded  than  with  the  “polysat”  designs. 

The  next  consideration  of  the  team  was  to  choose  a  satellite  bus  structure  that  best 
suits  the  goals  for  “low-cost”  and  ‘1aunch-on-need.”  Figure  6-10  below  depicts  just  a  few 
possible  structural  designs.  In  considering  these  designs  the  team  evaluated  how  each 
could  be  molded  into  a  “polysat”  design  based  on  the  following  objectives: 

Modularity  and  Subcomponent  Accessibility:  How  modular  is  the  design  and  how 

accessible  is  it  for  removal  and  replacement  of  subassembly  components? 

Materials  Usage;  Does  this  design  minimize  the  use  of  materials  in  its  construction? 

Structural  riaiditv:  What  is  the  inherent  strength  of  the  structure? 

Manufacturina;  The  difficulty  of  constructing  the  structure 
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Figure  6-10:  Satellite  Bus  Types 


Caee:  The  structure  is  made  up  of  a  variable  number  of  sides  with  each  comer 
constmcted  with  a  load  bearing  beam.  This  design  is  the  closet  to  the  “polysat”  design 
discussed  earlier.  Although  this  design  received  high  marks  for  modularity  and 
manufacturing,  it  scored  below  average  in  material  usage  and  structural  rigidity. 

Truss:  This  structure  mimics  those  used  for  fiiture  space  constmctions.  This  design 
scores  above  average  in  all  categories  except  for  modularity  . 

Blocks:  This  design  incorporates  the  bolting  together  of  subassembly  components. 
The  block  design  is  the  strongest  of  all ,  but  at  the  expense  of  added  weight  and 
machining. 

Shelf:  Most  satellite  designs  use  the  box  frame  with  shelves  to  layer  the  placement  of 
payload  and  subassembly  components.  This  type  of  design  received  average  scores  for 
material  usage  and  manufacturing,  and  below  average  scores  for  modularity  and 
stmctural  rigidity. 
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Drawer;  This  structure,  a  modified  “Shelf’  design,  incorporates  a  pull-out  and  plug¬ 
in  design.  Although  its  modularity  score  improved,  the  drawers  add  extra  weight  and 
complexity  to  the  design. 

Although  it  was  determined  that  Modsat  should  have  a  “polysaf  ’  structure,  the  best 
polysat  configuration  can  only  be  found  upon  modeling  the  complete  Modsat  bus  design. 
Second,  the  team  reviewed  both  current  and  revolutionary  designs  to  determine  the  best 
functional  design.  Both  the  “Cage”  and  the  “Truss”  scored  well,  but  the  “Truss”  design 
will  require  additional  harnesses  and  brackets  to  support  subcomponent  attachments. 
Therefore,  the  team  decided  to  design  Modsat  with  the  “Cage”  configuration,  which  best 
supports  the  “polysat”  design. 


6.5.3. 1  Polysat  Design 

Since  it  was  determined  that  the  best  shape  for  Modsat  is  a  “polysat”,  it  is  necessary  to 
find  the  optimal  number  of  sides  to  build  the  Modsat  bus  structure. 

Although  the  number  of  sides  is  a  design  variable  that  can  be  specified  in  the  model, 
this  number  should  be  minimized.  By  doing  so,  more  space  is  allowed  between  support 
beams,  granting  greater  side  access  to  the  subcomponents.  The  other  consideration  is  the 
solar  panels.  As  the  number  of  sides  increases,  so  does  the  number  of  folds  in  the  solar 
array  structure  (see  Figure  6-1 1).  This  increases  the  complexity  of  the  solar  panel  design 
and  reduces  the  reliability  of  its  structure.  The  main  driver  is  to  select  the  minimum 
number  of  sides  to  obtain  the  solar  panel  area  necessary  to  meet  power  requirements. 
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Through  extensive  modeling  the  octagon  was  chosen  as  the  baseline  structure  because  it 
makes  good  use  of  the  LV  fairing  volume  while  meeting  power  requirements. 


6.5.3.1.1  Solar  Panels 

The  requirement  for  large  amounts  of  electrical  power  played  an  important  part  in  the 
design  of  the  Modsat  structure.  To  meet  the  power  supply  goal  of  up  to  500  watts, 
considerably  large  solar  panels  are  necessary.  Modeling  for  the  electrical  power 
subsystem  (EPS)  determined  that  up  to  seven  square  meters  of  solar  array  area  would  be 
required.  Thus,  the  determination  of  the  solar  wing  placement  and  deployment 
mechanisms  proved  to  be  a  sizable  challenge. 

Since  the  structural  design  focused  on  maximizing  internal  volume,  the  team 
discounted  the  use  of  a  folded-wing  configuration  for  the  stowed  arrays,  due  to  its 
inefficient  use  of  space  within  the  launch  vehicle  fairing.  The  team  also  considered  a 
deployment  scheme  similar  to  that  used  by  Milstar,  where  the  arrays  spread  out  accordion- 
style  from  a  small  canister.  Although  this  approach  saves  a  great  deal  of  space,  it  is  very 
technologically  complex  and  costly.  Therefore,  the  team  decided  to  wrap  the  solar  array 
assemblies  around  the  bus  as  shown  below  in  Figure  6-11. 
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Figure  6-11:  Top  View  of  the  Solar  Panel  Configuration  During  Launch 

In  this  configuration,  the  solar  array  assemblies  must  be  constructed  and  hinged  so  as  to 
fold  around  the  polygon  perimeter  of  the  bus  shown  in  Figure  6-11.  This  technique  makes 
efficient  use  of  the  space  within  the  launch  vehicle  fairing  by  placing  the  solar  panels  along 
the  perimeter  of  the  launch  vehicle’s  payload  bay.  Moreover,  since  the  most  severe  launch 
loads  are  in  the  axial  direction,  the  vertical  placement  of  the  arrays  has  structural 
advantages. 

It  was  decided  that  in  order  to  simplify  the  design  and  construction  of  the  solar  array 
assemblies,  they  would  not  be  allowed  to  extend  in  height  beyond  the  curve  in  the  Pegasus 
fairing.  Any  protrusion  beyond  this  curve  would  require  the  use  of  special  hinges  and 
mechanisms,  which  would  drive  up  cost  and  decrease  the  structural  reliability  of  the 
assemblies.  Therefore,  the  maximum  height  of  the  stowed  solar  arrays  is  dictated  by  the 
distance  from  the  LV-to-spacecraft  interface  plane  to  the  curve  in  the  fairing. 
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6.5.4  Thermal  Control 


6.5.4. 1  Introduction 

Thermal  design  begins  with  defining  its  purpose.  As  the  name  implies,  thermal 
design  is  concerned  with  constructing  a  thermal-control  subsystem  ...  to  maintain  all 
elements  of  the  spacecraft  system  within  their  temperature  limits  for  all  mission  phases” 
(McMordie,  1992:409).  In  eveiy  satellite  design,  the  designer  must  consider  the  thermal 
impacts  due  to  the  sun,  the  earth,  and  internal  heat  generation.  Considering  each  of  these 
thermal  sources  is  important  to  ensuring  the  subcomponents  within  the  mission  module  or 
satellite  bus  operate  within  their  prescribed  temperature  ranges  shown  in  Table  6-4. 


Table  6-4:  Typical  Spacecraft  Component  Design  Temperatures 


Component  or  subsystem 

Operating  Temperature 
(degrees  in  C) 

Survival  Temperature 
(degrees  in  C) 

Digital  electronics 

0  to  50 

-20  to  70 

Analog  electronics 

0  to  40 

-20  to  70 

Batteries 

10  to  20 

0  to  35 

Infrared  detectors 

-269  to -173 

-269  to  35 

Solid-state  particle  detectors 

-35  to  0 

-35  to  35 

Momentum  wheels,  motors,  etc. 

0to50 

-20  to  70 

Solar  panels 

-100  to  125 

-100  to  125 

Source;  Wingate,  1994:433 


Just  as  the  table  suggests,  the  extent  of  thermal  analysis  depends  on  the  thermal  sensitivity 
of  the  satellite’s  subcomponents.  As  pointed  out  by  McMordie,  the  power  system  has  the 
greatest  impact  on  the  thermal  design  because  of  the  electrical  energy  being  dissipated 
throughout  the  satellite  and  the  tight  operating  temperature  limits  of  the  batteries 
(McMordie,  1992:411). 
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6.SA.2  Thermal  Design  and  Modeling 

Thermal  control  can  be  accomplished  either  actively  or  passively,  or  both.  The  team 
decided  from  the  start  to  maximize  the  use  of  passive  systems  to  minimize  cost,  weight, 
and  the  power  required  of  active  systems  (McMordie,  1992:413),  Since  “...preliminary 
mission  design  indicates  that  unmanned,  low-Earth  orbit  spacecraft  can  be  controlled 
passively”,  active  systems  were  not  investigated  in  this  study  (McMordie,  1992:413). 
Therefore,  passive  systems  such  as  thermal  coatings,  thermal  insulation,  and  space 
radiators  are  ideal  devices  for  meeting  thermal  constraints  in  a  satellite  design  (McMordie, 
1992:411). 

6.5.4,3  Designing  Thermal  Interface  Plate  Protection 

To  support  the  bus/mission  module  design  discussed  in  the  structure’s  trade  study,  the 
team  designed  a  thermal  blanket  constructed  of  woven  insulation  to  be  placed  directly 
below  the  top  interface  plate,  as  shown  in  Figure  6-12.  This  blanket  (under  the  mission 
module  interface  plate)  will  reduce  the  heat  transfer  between  the  bus  (cage  structure)  and 
the  mission  module  (on  top  of  mission  module  interface  plate)  by  restricting  temperature 
changes  between  the  two  structures. 


77 


Figure  6-12:  Thermal  Protection  of  the  Satellite  Bus/Mission  Module  Interface 

This  preliminary  analysis  concentrated  on  the  100  °C  differential  of  a  typical  bus 
structure  as  the  baseline.  Depending  on  the  temperature  required  by  the  mission  module, 
the  minimum  thickness  of  the  woven  insulation  to  preclude  a  1 5  degree  Celsius  change 
between  either  the  plate  or  the  mission  module  can  be  calculated  (see  calculations  in 
Appendix  C).  For  Modsat,  the  team  designed  a  4  cm  thick  interface  blanket. 


6.5.5  Telemetry,  Tracking,  and  Commanding/Command  and  Data  Handling,  and 
Communications 

Three  different  tradeoffs  affected  the  Telemetry,  Tracking,  Commanding 
(TT&CyCommand  and  Data  Handling  (C&DH),  and  Communications  Subsystem.  The 
tradeoffs  occurred  in  the  areas  of  communication  systems,  command  and  data  handling 
system,  and  the  type  of  components  to  be  used  in  the  satellite  bus  design. 
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6.5.5. 1  Communications 


Communications  systems  are  very  straight  forward  functions  for  a  satellite.  The 
system  consists  of  equipment  necessary  to  relay  commands  to  the  vehicle  from  the  ground 
and  to  send  health,  status,  and  in  some  cases,  payload  (mission  module)  data  from  the 
satellite  to  the  ground.  The  sponsor  indicated  that  the  bus  communications  system  had  to 
be  compatible  with  the  Air  Force  Satellite  Control  Network  (AFSCN).  The  Space 
Ground  Link  System  employed  by  the  AFSCN  imposed  a  limit  on  how  much  data  could 
be  transmitted  to  the  ground.  Since  it  was  not  uncommon  for  a  satellite  bus  to  employ 
two  separate  communications  systems,  the  team  decided  that  allowances  had  to  be  made 
to  support  a  separate  high  data  rate  communications  system.  To  provide  flexibility  for  the 
user,  the  satellite  could  be  included  as  part  of  the  mission  module  design  or  a  dedicated 
area  on  the  satellite  bus  could  be  made  available  for  a  high  data  rate  transceiver  and 
antenna.  A  restriction  was  levied  on  the  high  data  rate  communications  system.  In 
addition  to  its  primary  function  of  downlinking  mission  module  data,  the  system  was 
required  to  interface  with  the  satellite  bus  command  and  data  handling  system. 

6.5.5.2  Command  and  Data  Handling 

The  command  and  data  handling  system  offered  the  team  another  area  for 
tradeoffs.  The  conventional,  or  nominal,  design  of  a  command  and  data  handling  (C&DH) 
system  requires  that  both  the  command  and  telemetry  equipment,  plus  associated  data 
lines,  be  hard-wired  together.  The  command  decoder,  telemetry  format  unit,  and 
controller  are  usually  contained  within  a  single  unit  called  the  command  and  telemetry 
unit.  The  C&DH  functions  operate  under  the  direction  of  the  controller.  The  controller 
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maintains  the  satellite  timing  and  determines  command  priority  if  more  than  one 
commanding  system  is  in  use.  Figure  6-13  shows  the  fimctional  relationships  for  a 
nominal  C&DH  subsystem. 


Command  and  Telemetry  Unit 


Figure  6-13:  Nominal  Style  of  Command  and  Data  Handling 

An  alternate  Command  and  Data  Handling  architecture  involves  the  use  of  a 
Satellite  Operating  System  (SOS)  which  enables  an  extremely  broad  range  of  modularity 
Using  software,  the  main  processor  can  perform  the  process  of  decryption/encryption, 
command  controller  functions,  and  data  compression  algorithms.  Subsystem  interfaces 
route  through  the  Interrupt  Request  (IRQ)  processor  which  handles  traffic  deconfliction 
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and  prioritization.  Instead  of  conventional  hard-wired  interfaces  among  subsystems, 
modular  subsystems  route  their  functional  requests/needs  through  the  central  processor 
which  prioritizes  subsystem  requirements  in  view  of  overall  satellite  operations. 
Subsequently,  appropriate  action  is  directed  to  the  proper  subsystem  in  a  format 
understood  by  the  modular  subsystem.  In  essence,  SOS  provides  an  interface  to  allow 
vastly  different  subsystems  to  communicate  to  each  other  and  work  together  through  a 
baseline  structure.  Further  advantage  is  gained  by  the  ability  to  change  SOS  on  the  fly 
while  the  satellite  is  in  orbit,  through  the  uploading  of  new  software  to  the  central 
processor.  A  block  diagram  is  shown  in  Figure  6-14: 


Figure  6-14:  Proposed  Style  of  Command  and  Data  Handling 
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A  subsystem  design  trade-off  was  performed  between  the  nominal  C&DH  design 
and  the  Satellite  Operating  System.  The  Satellite  Operating  System  was  selected  as  the 
baseline  for  the  satellite  bus  design.  This  system  was  selected  over  the  conventional 
means  because  the  SOS  offers  more  advantageous  characteristics.  The  SOS  will  be  a 
lighter-weight  design  because  software  can  replace  some  of  the  subsystem  hardware. 

For  example,  software  code  can  replace  the  command  matrix  board,  the  encryptor,  and 
the  decryptor  hardware.  SOS  offers  yet  another  advantage.  SOS  has  a  means  for 
modifying  the  downlink  of  health  and  status  data  in  a  more  user  fnendly-manner. 

Software  code  can  permit  the  formatting  of  satellite  telemetry  data  in  such  a  manner  that 
telemetry  data  can  be  accessed  by  ground  users  in  much  the  same  way  that  users  access 
the  internet. 

Another  reason  for  the  selection  of  the  SOS  is  that  it  is  modular  in  nature.  The 
modular  characteristics  of  the  system  allow  for  the  easy  addition  or  removal  of 
components  to  the  C&DH  subsystem.  By  having  the  IRQ  checks,  the  system  could 
operate  with  or  without  the  additional  components.  If  a  component  is  not  connected  to 
the  bus,  the  SOS  would  be  aware  of  this  status.  If  a  component  is  added,  “driver” 
software  would  be  resident  within  the  SOS  program  that  checks  to  see  if  the  added 
component  is  available  for  operation.  Another  advantage  of  the  selection  of  SOS  is  that 
the  C&DH  code  could  be  modified  while  the  spacecraft  is  in  flight.  While  some  spacecraft 
permit  Attitude  Control  Subsystem  modification,  C&DH  subsystem  modification  is  not  an 
option  on  most  current  satellite  designs. 
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6.5.5.3  Component  Selection 


Component  selection  was  the  last  area  where  tradeoffs  where  performed  for  this 
subsystem.  In  order  to  select  components  for  the  design  study,  several  companies  were 
solicited  for  information.  One  of  the  goals  of  the  study  was  to  use  commercial  off  the 
shelf  components  were  possible.  Components  from  other  satellite  programs,  as  well  as  the 
Jet  Propulsion  Laboratory  (JPL)  and  the  Naval  Research  Laboratory,  provided  the  team 
with  TT&C/C&DH  component  information. 

The  Command  and  Data  Handling  components  chosen  for  the  generic  satellite  bus 
design  were  primarily  rated  on  their  performance-to-mass  ratios.  Cost  was  not  a  deciding 
factor.  Discussions  with  satellite  designers  and  engineers  such  as  Richard  Warner  of 
Aero  Astro,  Dave  Everett  of  NASA/Goddard  Space  Flight  Center,  and  Joel  Hagan  of 
Phillips  Laboratory’s  MightySat  Program,  revealed  that  Command  and  Data  Handling  is 
one  of  the  most  critical  subsystems  on-board  the  satellite  (Warner,  1996;  Everett,  1996; 
Hagan,  1996).  Without  the  proper  functioning  of  this  subsystem,  the  mission  of  the 
satellite  would  be  lost.  With  this  in  mind,  it  was  decided  that  only  space-rated  products 
should  be  used  in  the  design  of  this  subsystem. 

Other  factors  were  considered  in  the  selection  of  components.  A  requirement  for 
the  transceiver  and  antenna  is  that  they  must  be  compatible  with  the  Space  Ground  Link 
System.  Cincinnati  Electronics  provided  information  on  a  small  transceiver  that  provided 
the  correct  frequencies  for  communicating  with  the  Air  Force  Satellite  Control  Network. 
The  amount  of  memory  provided  by  a  data  storage  device  is  also  an  important  factor, 
since  the  satellite  needs  the  capacity  to  store  both  mission  module  data  and  state  of  health 
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data.  The  Clementine  Program  provided  a  data  storage  device  that  provided  2  Gigabytes 
of  data  for  a  mass  of  only  3.4  kilograms.  Other  data  storage  devices  considered  were 
much  more  massive.  Realizing  that  a  Satellite  Operating  System  architecture  would 
require  strong  computing  power,  the  team  chose  a  radiation  hardened,  32-bit,  high  speed 
Reduced  Instruction  Set  Computer  (RISC)  architecture  employing  Very  High  Speed 
Integrated  Circuit  (VHSIC)  technology.  This  computer  was  developed  by  Honeywell  for 
the  Ballistic  Missile  Defense  Office.  The  associated  controller  and  memory  modules  were 
developed  under  sponsorship  of  the  Naval  Research  Laboratory.  The  computer  and  its 
associated  controller  were  light  weight  and  extremely  power&l. 

Specific  components  were  not  selected  for  the  high  data  rate  communications 
system.  As  part  of  the  design  study,  it  was  decided  that  the  mission  module  developers 
would  provide  a  transceiver  and  antenna  for  the  satellite  bus.  This  arrangement  provides 
more  flexibility  for  the  mission  module.  Interface  data,  power,  mass,  and  size 
requirements  would  be  provided  to  the  mission  module  developers  to  assure  compatibility 
with  the  Satellite  Operating  System.  In  the  concept  of  operations,  the  use  of  the  Satellite 
Operating  System  would  allow  easier  integration  of  a  high  data  rate  communications 
system. 
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6.5.6  Electrical  Power 


6.5.6. 1  Objectives 

An  emphasis  was  placed  on  using  readily  available,  relatively  inexpensive 
components.  EPS  design  also  emphasized  the  use  of  proven  components  and 
architectures.  In  order  to  maximize  the  flexibility,  an  effort  was  made  to  accommodate 
modularity  and  ease  of  integration. 

The  primary  objective  for  EPS  design  is  to  provide  sufficient  power  for  the 
possible  range  of  mission  modules.  The  EPS  must  accommodate  the  most  power-hungry 
applications  planned  to  be  flown  on  Modsat.  Thus,  a  large  amount  of  power  must  be 
available  for  the  mission  modules.  However,  not  all  configurations  will  require  all  the 
available  power.  A  sound  systems  engineering  approach  must  consider  the  impact  of 
excess  power  (thermal  effects,  inefficient  use  of  weight,  etc.). 

6.5.6.2  Functional  Allocation 

The  EPS  consists  of  four  major  functional  areas,  as  shown  in  Figure  6-15;  power 
source;  energy  storage;  power  distribution;  and  power  regulation  and  control.  A  simple 
block  diagram  of  the  EPS  is  shown  in  Figure  6-16. 


Source:  McDermott,  1992:391 

Figure  6-15:  Electrical  Power  Subsystem  Functions 
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Figure  6-16:  EPS  Block  Diagram 

6.5.6.3  Power  Source 

The  power  source  generates  electrical  power  for  the  spacecraft,  supporting  the 
electrical  loads  over  many  orbits.  The  power  generation  system  of  choice  for  Modsat  is 
photovoltaic  solar  cells.  Solar  photovoltaics  are  the  typical  power  source  for  LEO 
spacecraft.  They  are  proven  and  widely  available.  Solar  power  is  adequate  for  the 
intended  mission,  and  lighter  (in  terms  of  specific  power)  than  the  other  alternatives. 
Although  there  are  cheaper  sources,  i.e.,  solar  thermal  dynamic  and  nuclear  reaction,  these 
alternatives  require  more  mass.  Nuclear  reactors,  furthermore,  require  a  fuel  that  has 
limited  availability,  while  solar  energy  is  unlimited.  Reactors  are  appropriate  for 
applications  requiring  a  large  amount  of  power,  but  not  for  the  loads  and  environment 
expected  for  a  small,  tactical  LEO  spacecraft  such  as  Modsat.  The  same  can  be  said  of  the 
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solar  thermal  dynamic  alternative.  The  radioisotope  alternative  is  very  cost  prohibitive. 
Given  the  strong  emphasis  on  affordable  access  to  LEO  missions,  the  radioisotope 
alternative  was  ruled  out. 

Solar  cells  must  be  mounted  on  solar  array  assemblies.  The  arrays  should  be 
planar  and  oriented  toward  the  sun  (Reeves,  1992:317).  The  power  output  is  proportional 
to  the  amount  of  sunlight  incident  on  the  panels.  Thus,  the  spacecraft  should  track  and 
point  the  arrays  for  maximum  incidence. 

Planar  arrays  may  be  body-  or  panel-mounted.  The  team  decided  to  use  panel- 
mounted  solar  arrays,  on  deployable  booms,  for  Modsat.  Following  are  reasons  for  this 
decision: 

•  Panel-mounted  arrays  are  usually  mounted  on  deployable  booms  that  rotate  the  panels 
for  maximum  incident  sunlight. 

•  Though  body-mounted  arrays  reduce  the  requirement  for  tracking  and  pointing,  they 
achieve  less  effective  sun  incidence  angles  and  power  conversion  efficiencies  than 
deployable  panels. 

•  There  may  not  be  enough  available  area  on  the  body  of  the  spacecraft  for  body- 
mounted  arrays  to  provide  the  required  power.  - 

•  With  deployable  booms,  it  is  easier  to  place  the  panels  away  fi'om  payload  instruments 
and  other  temperature  sensitive  subsystems  that  could  be  damaged  from  the  highly 
variable  temperature  environment  of  solar  cells. 
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On  the  other  hand,  panel-mounted  arrays  on  booms  add  appendages  to  the 
spacecraft  that  add  to  the  mechanical  complexity  and  take  up  precious  space  within  the 
launch  vehicle  fairing. 

The  team  recommends  the  modular  solar  array  approach  used  by  NASA’s  Small 
Explorer  (SMEX)  Program  (Everett,  1996),  as  well  as  Phillips  Laboratory’s  MightySat  n 
spacecraft  (Hagan,  1996),  for  the  following  reasons: 

•  It  is  desirable  to  minimize  the  amount  of  excess  power  on  Modsat. 

•  It  is  more  economical  to  limit  the  size  of  the  solar  array  structure  to  the  size  necessary 
to  produce  the  required  power. 

•  Flexibility  in  the  design  and  integration  of  each  spacecraft 

•  With  the  modular  approach,  the  engineers  can  build  the  solar  array  assemblies  much 
later  in  the  overall  process  of  spacecraft  construction  (Everett,  1996). 

In  the  modular  approach,  a  solar  array  is  constructed  of  smaller  solar  modules. 
These  modules  are  essentially  small  solar  panels  (8”  by  16”  for  the  SMEX  program), 
which  can  be  purchased  in  mass  quantities  (at  reduced  prices)  long  before  assembly.  Once 
the  required  power  for  the  spacecraft  is  determined,  the  appropriate  number  of  modules 
can  be  pulled  from  storage  and  integrated  into  a  customized  solar  array  assembly.  This 
assembly  consists  mainly  of  a  structural  grid  for  inserting  the  solar  modules.  It  must  be 
built  so  as  to  conform  to  the  chosen  stowed/deployed  configurations  for  the  spacecraft. 

Although  the  modular  solar  array  approach  is  recommended,  the  team  decided  to 
design  each  of  the  alternative  Modsat  concepts  with  maximum  power  for  the  sake  of 
designing  to  the  most  difficult  set  of  requirements. 
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During  launch,  the  arrays  will  be  wrapped  around  the  bus  in  the  stowed 
configuration.  Thus,  the  amount  of  surface  area  provided  by  the  bus,  combined  with  the 
number  of  wraps,  determines  the  power  generation  capability  of  the  arrays,  depending  on 
the  efficiency  of  the  solar  cells. 

Either  silicon  (Si)  or  gallium  arsenide  (GaAs)  cells  could  be  used  on  Modsat. 

Silicon  is  a  clear  choice  for  consideration.  It  is  a  proven,  mature  technology  that  has  been 
the  industry  standard  for  years,  although  it  is  more  bulky  and  less  survivable  than  other 
materials.  Gallium  arsenide  is  also  a  proven  technology,  and  is  becoming  more  and  more 
common  on  spacecraft.  Although  it  is  expensive  compared  to  silicon,  alternatives  for 
which  mass  and  volume  become  critical  may  require  the  use  of  galUum  arsenide. 

In  the  EPS  design  portion  of  the  Modsat  model  (see  Volume  III),  one  can  choose 
either  silicon  or  gallium  arsenide  as  the  solar  cell  material.  However,  throughout  the 
design  process,  it  became  clear  that  silicon  cells  would  not  provide  enough  power  per  area 
to  satisfy  the  requirement  of  the  CDM  (up  to  500  watts),  given  the  stowed  configuration 
limitation  on  the  size  of  the  arrays.  Thus,  all  of  the  Modsat  alternatives  were  designed 
with  gallium  arsenide  solar  cells. 

The  solar  arrays  must  be  sized  to  provide  the  required  power  at  the  end  of  the 
spacecraft  life.  Thus,  the  arrays  must  be  large  enough  to  account  for  the  degradation  that 
occurs  over  time. 

A  final  consideration  for  the  solar  arrays  is  the  selection  of  solar  array  drive  motors 
(SADMs).  SADMs  are  necessary  to  mechanically  rotate  the  solar  array  structures  to 
achieve  optimum  angles  of  incidence  with  sunlight.  Two  SADMs  are  needed,  one  for 
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each  solar  array.  For  modeling  purposes,  representative  SADMs  were  chosen  from  the  Jet 
Propulsion  Laboratory  (JPL)  Flight  Hardware  Survey,  with  the  following  characteristics: 

•  Mass;  5  kg  each. 

•  Dimensions;  Each  is  a  cylinder,  10  cm  diameter  by  27  cm  length. 

6.5.6.4  Energy  Storage 

Since  Modsat  will  not  be  generating  power  with  a  constant  source,  such  as 
radioisotopes  or  nuclear  reaction,  a  system  must  be  designed  to  store  energy  for  eclipse 
operations.  The  storage  system  must  also  be  able  to  handle  peak  loads  beyond  the 
capability  of  the  solar  arrays,  which  are  designed  to  handle  average  loads. 

The  most  common  storage  devices  for  LEO  spacecraft  are  chemical  batteries, 
known  as  secondary  batteries  since  they  discharge  during  eclipse  and  recharge  in  sunlight 
(McDermott,  1992:402).  Other  storage  schemes  are  available,  such  as  thermal  storage, 
but  they  are  far  less  common  for  LEO  spacecraft  than  batteries.  Some  new  approaches, 
such  as  flywheel  storage,  require  much  less  weight  than  batteries.  However,  it  was 
decided  that  new  approaches  with  unproven  technology  would  not  be  appropriate  for  the 
Modsat  EPS.  Space  batteries  are  commonly  used  and  widely  available,  and  are  therefore 
appropriate  for  Modsat  energy  storage. 

The  two  primary  types  of  batteries  in  use  today  are  nickel  cadmium  (NiCd)  and 
nickel  hydrogen  (NiH2)  batteries.  Nickel  cadmium  is  a  proven,  easily  available  and 
comparatively  cheap  technology,  but  it  delivers  a  relatively  low  energy  density.  Nickel 
hydrogen  delivers  more  energy  per  kilogram  than  nickel  cadmium,  but  it  is  more 
expensive.  However,  the  cost  objective  received  a  lower  priority  than  that  of  mission 
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utility.  Although  NiH2  is  a  less  mature  technology  for  LEO  applications  (McDermott, 
1992:403),  in  recent  years  it  has  been  used  successfully  in  many  spacecraft.  The  new 
common  pressure  vessel  (CPV)  design  nickel  hydrogen  technology  was  successfully 
qualified  on  the  Clementine  mission  in  1994  (Clementine  Report). 

Since  the  CDM  requested  a  peak  power  capability  of  1000  watts,  Modsat  requires 
a  great  deal  of  battery  capacity.  The  weight  of  the  bus  must  be  minimized;  therefore, 
nickel  hydrogen  was  preferred  by  the  team.  In  fact,  in  an  effort  to  drive  down  weight,  the 
team  decided  to  design  all  alternatives  with  two  nickel  hydrogen  CPV  batteries  from 
Johnson  Controls,  the  same  battery  flown  on  the  Clementine  mission.  Characteristics  of 
this  battery  are  shown  in  Table  6-5.  This  design  choice  gives  Modsat  30  amp-hours  of 
battery  capacity. 

Table  6-5:  Characteristics  of  the  Johnson  Controls/Clementine  NiH2  CPV  Battery 


#  of  cells 

Capacity 

Energy  density 

Dimensions . 

Weight 

(amp-hour) 

(W  hr/kg) 

(cm) 

(kg) 

22 

15 

47.1 

50.8  X  13.4  X  13.4 

9.5 

Source:  Clementine  Report 


More  flexible  alternatives  were  examined,  such  as  a  modular  scheme  employing 
several  low-capacity  batteries.  However,  in  keeping  with  the  importance  of  minimizing 
weight  and  maximizing  capabiUty,  modularity  was  sacrificed  for  a  low  weight,  high  power 
battery  choice. 

The  batteries  were  sized  to  handle: 

•  Required  power  during  eclipse 

•  Peak  power  demands  (supplementing  the  solar  arrays) 


91 


6.5.6.5  Power  Distribution 


The  power  distribution  system  consists  of  the  cabling,  fault  protection,  and  power 
switching  gear  to  turn  power  on  and  off  to  the  spacecraft  loads.  A  major  focus  in 
distribution  system  design  is  on  keeping  mass  and  power  losses  at  a  minimum  while 
providing  survivability,  cost,  reliability,  and  power  quality. 

Since  Modsat  is  intended  to  be  a  generic,  standardized  bus,  the  required  load  of 
the  mission  equipment  is  unknown  until  the  mission  need  arises.  Moreover,  flexibility  in 
configuration  is  a  key  value  of  the  decision  maker.  Therefore,  there  is  no  fixed  load 
profile  for  Modsat;  the  distribution  system  must  take  this  into  consideration. 

Mechanical  relays  are  the  clear  choice  for  power  switching,  “because  of  their 
proven  flight  history,  reliability,  and  low  power  dissipation”  (McDermott,  1992:405). 
Solid-state  relays  may  be  the  standard  choice  in  the  future,  but  presently  they  are  an 
immature  space  technology. 

Decentralized  distribution  is  the  best  approach  for  Modsat.  It  allows  for  a  great 
deal  of  flexibility,  thereby  complementing  a  modular  architecture.  Each  power-using 
component,  including  the  mission  module,  must  provide  its  own  converter/regulator.  The 
load  nodes  will  be  fixed,  but  the  load  users  may  be  changed.  This  scheme  obviates  the 
need  for  customizing  the  distribution  network  for  each  mission  application. 

The  distribution  system  should  include  provisions  for  fault  detection,  isolation,  and 
correction  during  testing  (McDermott,  1992:406).  Each  fully  integrated  Modsat 
spacecraft  must  undergo  extensive  testing,  especially  since  each  many  configurations  will 
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be  unique.  A  full  set  of  fuses,  placed  in  series  with  the  power  bus,  will  be  required  for 
fault  testing  (McDermott,  1992:407). 

The  wiring  can  have  up  to  4%  of  the  mass  of  the  dry  spacecraft  (Reeves, 

1992:3 19).  Since  this  is  not  a  trivial  amount,  it  is  important  to  keep  the  distribution  cables 
as  short  as  possible. 

For  modeling  purposes,  a  power  control  unit  (PCU)  was  chosen  from  JPL’s  Flight 
Hardware  Survey  to  represent  the  distribution  system.  This  unit  is  a  24  x  16  x  20  cm  box. 

6.5.6.6  Power  Regulation  and  Control 

Power  regulation  must  be  considered  for  three  key  elements:  controlling  the  solar 
array,  regulating  bus  voltage,  and  charging  the  battery  (McDermott,  1992:407).  Solar 
array  power  must  be  controlled  at  the  array  to  prevent  battery  overcharging  and  excessive 
spacecraft  heating  (McDermott,  1992:407). 

Two  primary  schemes  are  available:  a  peak-power  tracker  (PPT)  and  a  direct- 
energy-transfer  (DET)  system  (McDermott,  1992:407;  Everett,  1996).  A  PPT  is 
nondissipative;  it  extracts  the  exact  amount  of  required  power  up  to  the  array’s  peak 
output.  A  PPT  operates  in  series  with  the  solar  array,  and  uses  4-7%  of  the  total  power 
(McDermott,  1992:407).  The  DET  system  is  dissipative  because  it  shunts  all  power  not 
used  by  the  loads.  A  shunt  regulator  operates  in  parallel  to  the  array  and  shunts  the  array 
current  away  when  the  loads  or  battery  charging  do  not  require  the  power  (McDermott, 
1992:407). 

A  DET  system  should  be  used  as  opposed  to  a  PPT.  The  DET  has  fewer  parts, 
lower  mass,  and  higher  total  efficiency  (McDermott,  1992:407).  Moreover,  given  the  use 
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of  modular  solar  arrays,  different  Modsat  missions  will  have  different  amounts  of  power 
being  supplied.  A  simple  shunt-regulated  system,  i.e.,  the  DET  system,  would  aid  in  the 
integration  of  such  an  architecture. 

An  unregulated  system  should  be  used  to  control  bus  voltage,  since  regulation 
involves  the  dissipation  of  energy.  This  is  ineflBcient  and  could  potentially  create  heat  in 
undesirable  places. 

Batteries  can  be  charged  individually  or  in  parallel.  Parallel  charging  keeps  the 
voltage  of  all  batteries  the  same,  but  allows  current  and  temperature  to  vary  (McDermott, 
1992:409).  Individual  charging  “optimizes  the  battery  use  by  charging  all  the  batteries  to 
their  own  unique  limits”  (McDermott,  1992:409). 

Due  to  the  emphasis  on  design  flexibility,  it  seems  advantageous  to  employ 
independent  battery  chargers.  Their  use  aids  in  vehicle  integration  and  maximizes  the  use 
of  each  battery  (McDermott,  1992:409).  A  modular  battery  approach  would  be  greatly 
facilitated  by  the  use  of  independent  charging,  and  greatly  hampered  by  parallel  charging 
(Everett,  1996).  On  the  other  hand,  independent  charging  is  more  expensive  and 
complicated  than  parallel  charging  (McDermott,  1992:409),  and  adds  more  weight.  The 
current  tradeoff  of  cost  for  mission  utility  led  the  team  to  recommend  the  independent 
charging  approach. 

For  modeling  purposes,  a  shunt  regulator  was  chosen  from  JPL’s  Flight  Hardware 
Survey  to  represent  the  regulation  system.  This  unit  is  a  42  x  1 8  x  1 1  cm  box. 
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6.6  TradeofT  Summary 


6.6.1  System  Level 

•  One  satellite  per  launch  vehicle 

•  3 -axis  stabilization 

•  Modular  component  interfaces 

•  On-board  propulsion 

•  Mission  data  storage 

•  Spacecraft  to  Payload  Interface  Guideline  (SPIG)  interface 

6.6.2  Subsystem  Level 

ATTITUDE  DETERMINATION  AND  CONTROL 

•  Inertial  Measurement  Unit 

•  Star  sensor 

•  Earth  sensor 

•  Reaction  wheels 
PROPULSION 

•  Monopropellant  configuration 

•  Hydrazine  blend  propellant;  24%  HN,  76%  N2H4 

•  Blowdown  pressure  system 

•  Positive  expulsion  fuel  storage  system 

•  Bottom  level  location  for  the  system 

•  cylindrical  tanks 
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•  thrusters 


STRUCTURES 

•  Octagon  “cage”  structures  with  “polysat”  design 

•  Modular  mounting  plates 
THERMAL 

•  Interface  thermal  blanket  between  the  mission  module  and  satellite  bus 
TTC/CDH 

•  Satellite  Operating  System 

»  software  handles  interrupt  requests  to  collect  telemetry  and  handle  housekeeping 

•  Internet  communication  format  (TCP/IP) 

»  JAVA  compatible  architecture  enables  user  in  field  to  access  data  via  browser 
capable  system 

»  provides  point-and-click  environment  to  control  satellite 
»  encryption  on  demand  with  software  plug-in  modules 
EPS 

•  Modular  solar  arrays  on  deployable,  articulated  booms 

•  Solar  arrays  wrap  around  the  bus  in  the  stowed  launch  configuration 

•  Gallium  arsenide  solar  cells 

•  NiHa  common  pressure  vessel  batteries 

•  Decentralized,  unregulated  distribution 

•  Shunt  regulation;  individual  battery  charging 
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7.  Modeling 


Models  play  an  important  role  in  solving  complex  and  multiple  variable  problems; 
as  such,  it  is  a  critical  element  of  systems  engineering.  To  use  systems  engineering  in 
designing  a  standardized  tactical  satellite  bus,  the  team  was  faced  with  many  variables  and 
the  relationships  amongst  them.  Satellite  design  by  its  very  nature  is  quite  complex,  and 
trying  to  account  for  every  detail  in  this  preliminary  study  is  infeasible.  Modeling  enabled 
the  team  to  approach  the  satellite  design  at  a  high  level,  focusing  only  on  the  major 
elements  of  the  spacecraft.  The  team  also  used  the  model  to  test  and  evaluate  the 
performance  of  the  alternative  solutions. 

Before  considering  modeling  methods,  it  was  important  to  revisit  the  problem 
definition,  the  objectives,  and  the  measures  of  effectiveness  (MOEs).  This  ensured  the 
modeling  effort  was  fully  relevant  to  solving  the  problem,  and  within  the  framework  of  the 
objectives,  the  model  would  be  able  to  evaluate  the  alternatives  proposed  to  solve  the 
problem. 

Once  the  basis  for  the  model  was  understood,  the  team  outlined  the  scope  and  type 
of  model  necessary  to  meet  the  objectives.  Starting  from  a  high  level,  the  team  determined 
the  model  must  be  highly  integrated  and  compatible;  the  best  way  to  satisfy  this 
requirement  was  to  use  one  program  for  all  of  the  modeling.  Once  the  model  produced  a 
satellite  design,  it  would  be  important  to  perform  some  level  of  environmental  and 
integration  testing  on  it.  Those  designs  meeting  the  testing  and  integration  modeling 
elements  required  data  analysis  to  assist  in  the  final  evaluation  of  how  the  alternatives 
ranked  with  each  other. 
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Although  these  requirements  for  an  integrated  model  appear  easy  to  fulfill,  they 
were  not.  The  research  conducted  on  the  Internet  found  satellite  software  modeling  still 
geared  toward  specific  subsystems.  Discussions  with  aerospace  companies  confirmed  our 
findings,  however,  they  mentioned  how  some  companies  are  now  using  computer  labs  to 
bring  subsystem  experts  together  for  satellite  design  sessions.  To  satisfy  all  the  modeling 
requirements,  it  was  necessary  to  develop  an  in-house  satellite  design  model,  using 
Matlab,  a  mathematical  and  graphics  software  package. 

To  meet  the  “integrable,  compatible,  and  adaptable”  modeling  requirement, 
Modsat  (Modular  Satellite)  was  constructed  and  built  around  a  generic  database  structure 
format.  By  constructing  all  the  subcomponents  with  the  same  generic  database, 
compatibility  among  all  the  subcomponents  was  achieved.  Once  the  subcomponent 
databases  were  constructed,  they  were  combined  into  a  single  satellite  database,  thus 
ensuring  the  overall  satellite  design  was  totally  integrable.  Modsat  satisfies  the 
“adaptability”  requirement  by  allowing  the  satellite  designer  to  modify  Modsat  in  three 
ways; 

•  Correct,  delete  and/or  expand  the  satellite  database. 

•  Make  changes  to  the  Modsat  code  substructure  to  incorporate  more  detailed 
analysis  or  changes  in  technology. 

•  Tie  into  other  external  programs 

Using  the  modeling  requirements  hsted  above,  Modsat  development  started  with  a 
high-level  structure  as  shown  in  Figure  7-1. 
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Build  satellite  components  and 
create  a  satellite  database 


Check  for  subsystem  overlap 
Check  weight  dimensions  against 
launch  vehicle  constraints 
Calculate  key  satellite 


Check  for  subsystem  interoperability 


Subject  the  satellite  to  various  test 


Take  test  results  and  report  how  well 
the  satellite  met  the  MOEs 


Figure  7-1:  Logical  Flow  of  Modsat  Model 


The  Modsat  model  is  geared  toward  sequential  operation,  starting  from  the  top  of 
the  logic  flow  diagram  and  working  down.  Each  step  provides  additional  information 
about  the  satellite  design,  and  at  any  given  step  the  satellite  design  can  be  stopped  to  be 
modified  or  re-accomplished. 

Building  satellite:  Build  subcomponent  databases  and  combine  them  into  one 
integrated  satellite  database. 

Test  Satellite:  Check  the  satellite  database  to  ensure  total  satellite  mass,  center  of 
mass,  and  sizing  meet  the  launch  vehicle  constraints.  If  the  satellite  design  fails  any  of 
these  tests,  the  satellite  design  must  be  either  scrapped  or  modified. 
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Initialize  Operating  System:  Once  the  satellite  design  passes  the  “test”  section,  the 
satellite  database  is  checked  for  subsystem  interoperability  such  as  power  requirements. 
This  section  also  calculates  cost  and  reliability  for  the  satellite  design. 

Run  Scenarios:  This  section  subjects  the  satellite  bus  to  launch  and  orbit 
environmental  testing  to  determine  its  overall  performance. 

Data  Analysis:  The  satellite  performance  parameters  are  fed  into  data  analysis 
either  directly  or  indirectly,  before  being  evaluated  against  a  set  of  objectives.  Each 
satellite  design  receives  an  overall  utility  score  as  well  as  an  overall  ranking  with  other 
designs.  To  complete  the  analysis  and  provide  some  variability  in  the  results,  sensitivity 
analysis  can  be  performed  by  modifying  and  rescaling  the  top  level  objective  weights. 

Although  the  Modsat  model  used  first  order  assumptions  and  calculations,  it 
proved  to  be  an  excellent  systems  engineering  tool,  allowing  the  team  to  design,  test,  and 
evaluate  satellite  designs.  For  a  full  description  of  the  model,  see  Volume  III. 
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8.  System  Synthesis 


8.1  Subsystem  Baselines 

Each  subsystem  level  study  addressed  the  selection  of  individual  components  and 
the  narrowing  of  requirements  for  each  satellite  subsystem.  These  components  then 
became  fixed  in  all  of  the  candidate  designs,  yielding  a  baseline  design  on  which  alternative 
configurations  could  be  based  by  varying  the  characteristics  and/or  configurations  of  the 
subsystems  not  fully  determined  by  the  tradeoff  studies.  This  streamlined  approach  to 
subsystem  and  eventual  system  design  facilitated  the  focusing  of  effort  and  the  effective 
utilization  of  extensive  satellite  subsystem  expertise  by  the  more  experienced  team 
members. 

8.2  Alternative  Design  Descriptions 

The  following  discussion  details  the  alternative  designs  evaluated  using  the  Modsat 
computer  modeling,  design,  and  analysis  software.  To  begin  scoping  the  alternatives,  all 
were  designed  to  be  compatible  with  the  Pegasus  XL/without  HAPS  configuration.  Of 
the  seven  designs,  six  are  based  on  the  38”  interface,  while  the  seventh  is  based  on  the  23” 
interface.  The  team  judged  early  in  the  design  process  that  the  23”  interface  configuration 
probably  would  not  provide  enough  volume  for  Modsat  because  it  reduces  volume  for  the 
mission  module  and  the  size  of  the  solar  arrays.  However,  one  alternative  with  this 
interface  was  generated  for  the  sake  of  a  complete  analysis. 
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The  designs  fall  into  one  of  two  categories.  In  the  first  category,  there  are  three 
levels  for  component  placement.  The  third  level  has  a  Supplemental  Mission  Adaptive 
Shelf,  or  “SMASH”,  which  is  a  large  volume  of  space  reserved  for  either  a  dedicated  high 
data  rate  antenna  and  its  transponder,  or  some  other  user-specified  payload  or  mission- 
unique  equipment.  The  second  category  has  only  two  levels,  reducing  the  overall  bus 
height  by  not  including  a  SMASH  for  additional  mission  equipment  (such  as  a  high  data 
rate  communications  package).  In  the  case  of  the  second  category  designs,  all  mission- 
unique  equipment  would  be  placed  entirely  on  the  payload  interface  plate  (very  top  of  the 
bus). 

All  designs  fit  a  particular  tactical  profile,  with  tactical  capability  being  determined 
by  the  amount  of  fuel  on-board.  Those  designs  with  more  fuel  have  more  ability  to  make 
in  plane  or  out  of  plane  maneuvers,  satellite  altitude  corrections,  or  other  maneuvers.  In¬ 
plane  changes  can  be  measured  by  AV;  thus,  total  AV  capability  is  the  measure  for  how 
much  a  satellite  can  change  its  velocity.  AV  capability  is  directly  proportional  to  the 
amount  of  fuel  carried  by  the  spacecraft.  All  of  the  designs  have  varying  amounts  of  AV 
capability  according  to  three  sizes  of  propellant  tanks  carried  by  the  spacecraft.  There  are 
three  profiles  for  AV;  max  (450  m/s),  mid  (300  m/s),  and  low  (100  m/s).  These  tactical 
profiles  correspond  to  varying  demands  which  may  or  may  not  be  placed  on  the  satellite 
during  its  mission.  For  a  given  category  the  three  tactical  profiles  are  essentially  the  same 
except  for  the  size  of  the  propellant  tanks.  Since  the  bottom  level  of  the  bus  is  reserved 
for  propulsion,  different  tank  sizes  will  raise  or  lower  the  bottom  mounting  plate,  thus 
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increasing/decreasing  the  overall  height  of  the  satellite  bus.  The  three  tactical  profiles  and 
their  capabilities  are  summarized  in  Table  8-1: 


Table  8-1:  Tactical  profiles 


MAXTAC 

Maximum  AV  capacity  for  orbit  maintenance 

Up  to  2.5  degrees  of  inclination  change  during  mission 

MIDTAC 

Median  AV  capacity  for  orbit  maintenance 

Up  to  1.5  degrees  of  inclination  change  during  mission 

LOWTAC 

Minimum  AV  capacity  for  orbit  maintenance  (one  year) 

All  designs  have  the  same  power  supply  capability  (447  Watts  average/1000  Watts 
peak),  except  for  the  23”  interface  design,  which  has  lower  output  (390  Watts  avg,  950 
Watts  peak)  due  to  less  area  for  the  solar  arrays.  The  seven  designs  generated  as 
alternative  solutions  are  as  follows; 

•  MAXTAC:  Max  tactical  profile,  with  three  component  levels  and  SMASH 

•  MIDTAC;  Mid  tactical  profile,  with  three  component  levels  and  SMASH 

•  LOWTAC;  Low  tactical  profile,  with  three  component  levels  and  SMASH 

•  MAXTAC-N:  Max  tactical  profile,  with  two  component  levels  and  no  SMASH 

•  MEDTAC-N;  Mid  tactical  profile,  with  two  component  levels  and  no  SMASH 

•  LOWTAC-N:  Low  tactical  profile,  with  two  component  levels  and  no  SMASH 

•  MIDT AC-23;  Mid  tactical  profile,  with  three  component  levels  and  SMASH;  23  inch 
interface 

The  major  characteristics  of  each  design,  including  the  height  of  each  bus,  were 
determined  through  modeling,  and  the  results  are  shown  in  Table  8-2  . 
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Table  8-2:  Major  Design  Characteristics 


Acronym 

SMASH 

Number  of 
Levels 

AV 

(m/s) 

Interface 

(in) 

Bus  Height 
(cm) 

MAXTAC 

Yes 

3 

450 

38” 

71 

MIDTAC 

Yes 

3 

300 

38” 

68 

LOWTAC 

Yes 

3 

100 

38” 

63 

MAXTAC-N 

No 

2 

450 

38” 

69 

MIDTAC-N 

No 

2 

300 

38” 

66 

LOWTAC-N 

No 

2 

100 

38” 

61 

MIDTAC-23 

Yes 

3 

300 

23” 

95.7 

8.3  Convei^ence  of  Individual  Designs 

Most  of  the  designs  are  very  similar,  except  for  the  category  and  tactical  profile 
differences;  once  an  initial  positioning  of  components  is  accomplished,  the  other  designs 
simply  incorporate  the  SMASH/no  SMASH  option  and  the  tactical  profile  (propulsion) 
options.  The  design  most  divergent  from  the  rest,  of  course,  is  the  design  based  upon  the 
Pegasus  launch  vehicle  23-inch  interface. 

The  process  of  design  convergence  begins  with  the  physical  constraints  placed 
upon  the  satellite  by  the  launch  vehicle  (in  this  case,  the  Pegasus).  Further,  the  main 
physical  dimension  constraining  the  bus  is  the  diameter  of  the  interface  (38  inches  for  the 
first  six  designs,  and  23  inches  for  the  seventh).  Starting  with  the  interface  plate  of  the 
launch  vehicle  and  proceeding  upwards  with  successive  component  “shelves”,  placement 
of  components  may  be  initially  estimated,  spatially  evaluated,  and  iteratively  adjusted,  until 
a  reasonable,  desirable  arrangement  of  components  solidifies  into  an  integrated  satellite 
design.  The  semi-cylindrical,  shelf-like  structure  chosen  for  Modsat  is  conducive  to  this 
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design  convergence  approach  and  facilitates  the  organization  of  components  into 
“functional”  groups. 


8.4  Component/Characteristic  Listing 


The  following  list  summarizes  the  set  of  characteristics  and  components  that  were 
chosen  for  Modsat.  It  should  be  clear  that,  to  be  consistent  with  the  scope  of  this  study, 
this  is  a  high-level  set  of  major  components.  The  rationale  behind  the  selection  of  these 
components  is  discussed  in  the  Tradeoffs  section  of  this  report.  Only  those  characteristics 
that  were  relevant  to  the  integration  of  the  overall  design  are  included  below. 

•  Launch  Vehicle  Fairing  Static  Envelope  (inside  of  which  the  spacecraft  may  be  placed) 
Note:  The  Pegasus  User 's  Guide  specifies  a  dynamic  envelope  of  46".  The  team 
decided  to  use  a  more  conservative  static  envelope  due  to  the  risk  inherent  in  the  use 
of  the  wrap-around  solar  array  assemblies.  This  approach  is  used  by  the  SMEX 
program  (Everett,  1996). 

•  Diameter:  44”»112cm 

•  Height  from  spacecraft  interface  to  curve  in  fairing:  1 1 1  cm 

•  Structures  and  Mechanisms 

Note:  All  structural  members  are  made  of  7075-T6  aluminum,  with  a  density  of 
2,800  kg/m{ 

•  Shape:  Octagon 

•  Structural  cylindrical  columns  (8) 

-  Dimensions:  hollow;  4  cm  outer  diameter;  1.5  cm  inner  diameter;  height 
varies  with  each  design 

•  LV  interface  plate 

-  Diameter:  1 1 1 .76  cm 

-  Thickness:  1  cm 

•  Component  mounting  plates  (2  for  with  SMASH,  1  for  no  SMASH;  note  that 
the  LV  interface  plate  forms  the  bottom  component  plate) 

-  Diameter:  87.26  cm 
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-  Thickness;  0.2  cm 


•  Center  spine 

-  Dimensions:  5  cm  square;  hollow;  height  varies  with  each  design 
•  Propulsion 

•  Propellant  tanks  (4) 

-  Dimensions:  hollow  cylinder;  2  tanks  are  42  cm  long,  2  are  33  cm  long; 
diameter  varies  with  tactical  profile 

•  Thrusters  (6) 

-  Dimensions:  modeled  as  a  cylinder;  6.6  cm  diameter;  10.2  cm  height 

•  Valves  (6) 

-  Dimensions:  modeled  as  a  cylinder;  6.6  cm  diameter;  8.2  cm  height 


•  ADCS 

•  Reaction  wheels  (4) 

-  Dimensions:  cylinder;  25.5  cm  diameter;  9  cm  height 

-  Mass:  5.1  kg  each 

-  Power  requirement:  17  watts  max 

•  Reaction  wheel  electronics  boxes  (4) 

-  Dimensions:  box;  17.8  by  15.2  by  3.2  cm 

-  Mass:  0.9  kg  each 

•  Earth  sensor  (head) 

-  Dimensions;  cylinder;  10.4  cm  diameter;  16.3  cm  length 

-  Mass;  1.27  kg 

-  Power  requirement:  0.5  watts 

•  Earth  sensor  (electronics) 

-  Dimensions:  box;  10.2  by  20.3  by  6.7  cm 

-  Mass:  1.14  kg 

-  Power  requirement:  3.5  watts 

•  Star  sensor 

-  Dimensions:  cylinder;  13.5  cm  diameter;  14.2  cm  length 

-  Mass:  2.5  kg 

-  Power  requirement:  10  watts 


106 


•  Inertial  Measurement  Unit  (IMU) 

-  Dimensions;  cylinder;  21.6  cm  diameter;  13.3  cm  height 

-  Mass:  3.72  kg 

-  Power  requirement:  33  watts 

•  EPS 

•  Solar  array  panels  (16) 

Note:  Since  the  bus  has  an  octagon  shape,  there  are  eight  hinged  panels  per 
wrap  around  the  bus.  All  configurations  used  two  wraps,  therefore  all  have 
16  panels. 

-  Dimensions:  box 

—  Thickness:  4  cm 

-  Width:  inner  wrap  panels  are  36. 14  cm  wide;  outer  wrap  panels  are 
39.45  cm  wide 

“  Height:  varies  with  each  design 

-  Mass;  varies  with  size  of  arrays 

•  Batteries  (2  NiH2) 

-  Dimensions;  cylinder;  13.4  cm  diameter;  50.8  cm  length 

-  Mass:  9.5  each 

-  Capacity:  15  amp-hours  each 

•  Regulator 

-  Dimensions;  box;  42  by  18  by  11  cm 

-  Mass;  varies  with  power  output 

•  Power  Control  Unit  (PCU) 

-  Dimensions:  box;  24  by  16  by  20 

-  Mass:  varies  with  power  output 

•  Solar  Array  Drive  Motors  (2  SADMs) 

-  Dimensions:  cylinder;  10  cm  diameter;  27  cm  length 

-  Mass:  5  kg  each 

•  TT&C/CDH 

•  Transceiver 

-  Dimensions:  box;  21  by  15  by  13  cm 

-  Mass:  3.41  kg 

-  Power  requirement:  22  watts 

•  SGLS  Antennas  (2) 

-  Dimensions:  cylinder;  4  cm  diameter;  10.2  cm  height 


107 


-  Mass;  0.25  kg  each 

•  Central  Processing  Unit  (CPU) 

-  Dimensions;  box;  5  by  22  by  15 

-  Mass;  0.9  kg 

-  Power  requirement;  2.8  watts 

•  Data  Storage  Unit 

-  Dimensions;  box;  13  by  13  by  13 

-  Mass;  3.4  kg 

-  Power  requirement;  1  watt 


8.5  Baseline  Design 

The  MAXTAC  bus  (maximum  propulsion,  three  shelves  with  SMASH)  was 
chosen  as  the  baseline  upon  which  to  conduct  the  detailed  placement  of  components,  The 
following  discussion  applies  to  the  design  of  the  MAXTAC.  In  section  8.6,  the  other 
alternatives  will  be  discussed.  The  complete  set  of  databases  for  each  design  is  included 
with  the  modeling  software  (see  Volume  HI). 

With  the  basic  structure  at  hand,  the  team  had  to  choose  desired  locations  for  the 
components.  It  was  decided  to  place  the  components  as  shown  in  Table  8-3. 


Table  8-3:  Component  Placement 


Component  Level 

Components 

1st 

Propulsion;  one  SGLS  antenna 

2nd 

Batteries;  PCU;  Regulator;  Reaction  wheels 
and  electronics;  Earth  sensor  and  electronics; 

Star  sensor 

3rd 

IMU;  TTC  &  CPU  components;  SADMs 

The  rationale  for  locating  the  propulsion  subsystem  on  the  bottom  level  is 
documented  in  the  Tradeoffs  section  of  this  report.  It  was  decided  to  place  a  SGLS 
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antenna  on  the  bottom  level  as  well,  such  that  the  antenna  would  have  a  field  of  view 
through  a  hole  in  the  LV  interface  plate.  It  was  felt  that  an  antenna  was  necessary  in  this 
location  in  order  to  communicate  with  Modsat  prior  to  its  full  structural  deployment. 

The  team  decided  to  place  components  on  the  second  level  in  such  a  way  as  to 
keep  the  spacecraft  center  of  mass  as  low  as  possible  (due  to  LV  considerations).  Thus, 
the  relatively  massive  batteries  and  reaction  wheels  were  placed  on  the  second  level.  In 
order  to  collocate  as  many  subsystem  components  as  possible,  the  regulator,  CPU, 
reaction  wheel  electronics,  earth  sensor  and  electronics,  and  star  sensor  were  placed  on 
the  second  level  as  well. 

However,  it  was  necessary  to  place  the  SADMs  on  the  third  level.  The  axis  of  the 
SADMs  must  be  aligned  with  the  axis  of  the  solar  array  assemblies,  which  must  in  turn  be 
located  high  enough  to  provide  a  balanced  inertia  matrix  for  the  total  spacecraft.  In 
addition,  the  SADMs  must  be  placed  on  the  outer  edge  of  the  component  plate,  in  order 
to  mate  with  the  extended  solar  array  booms.  The  remaining  TT&C/CPU  components 
were  placed  on  the  third  level.  Nearly  one  half  of  the  third  level  was  reserved  for  the 
SMASH.  The  team  modeled  the  use  of  this  space  with  a  hypothetical  high  data  rate 
(HDR)  package,  consisting  of  an  antenna  and  a  transceiver.  The  antenna  was  modeled  as 
a  large  cylinder,  while  the  transceiver  was  chosen  to  be  identical  to  the  TT&C  transceiver. 

The  very  top  mounting  surface  of  the  bus  (designated  the  “payload  interface 
plate”)  serves  as  the  substructure  for  the  mission  modules.  Several  different  types  of 
mission  modules  may  be  evaluated  with  the  various  bus  designs  by  using  the  Modsat 
computer  model.  For  ease  of  evaluation  for  this  design  study,  the  mission  modules  are 
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oriented  in  the  axial  direction  because  the  on-orbit  attitude  for  the  Modsat  will  have  the 


payload  interface  plate  pointing  nadir.  Future  design  efforts  may  introduce  alternative 
orientations. 

Finally,  it  was  necessary  to  keep  the  spacecraft  center  of  mass  as  close  as  possible 
to  its  central  axis.  Thus,  mass  symmetry  was  a  major  factor  in  the  placement  of 
components. 

8.5.1  Structure 

Based  upon  the  AV  requirements  given  for  the  tactical  profile  desired,  the  height 
of  the  first  component  plate  was  set,  and  the  initial  positioning  of  components  could 
commence.  The  MAXTAC  structure  is  shown  in  Figure  8-2. 
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8.5.2  Propulsion 


Figure  8-3  shows  the  propulsion  subsystem  integrated  into  the  structure. 


Figure  8-3:  MAXTAC  Propulsion  Subsystem 

8.5.3  ADCS 

For  the  purpose  of  optimum  three-axis  control,  the  reaction  wheels  are  canted  at 
45  degree  angles.  The  sensor  components  are  placed  at  the  outer  edge  of  the  component 
plate,  such  that  they  have  a  field  of  view  through  holes  in  the  outer  bus  wall.  The  sensors 
face  directions  in  which  there  are  no  solar  arrays  blocking  the  view.  In  Figure  8-4,  the 
ADCS  components  are  shown  integrated  into  the  structure. 
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Figure  8-4:  MAXTACADCS 


8.5.4  EPS 

Due  to  the  placement  of  the  reaction  wheels,  the  batteries  hang  from  the  bottom  of 
the  2n(i  component  plate.  The  regulator  and  CPU  are  placed  symmetrically  where  space 
allows.  The  stowed  and  deployed  EPS  configurations  are  shown  in  Figure  8-5. 
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Figure  8-5:  MAXTACEPS 


8.5,5  TTC 

The  SGLS  antenna  on  the  third  component  level  is  placed  close  to  the  outer  edge 
of  the  bus.  This  antenna  must  be  deployed  on  a  boom  with  an  appropriate  mechanism. 
TT&C/CPU  components  are  shown  in  Figure  8-6. 
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Figure  8-6:  MAXTAC  TT&C/CPU 

8.5.6  MAXTAC  SMASH 

Figure  8-7  shows  the  top  level  of  the  bus,  with  the  SMASH  being  utilized  by  a 
high  data  rate  communications  package. 
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Figure  8-7;  MAXTAC  SMASH 


8.5.7  MAXTAC  Composite 


The  entire  MAXTAC  design  is  shown  in  Figure  8-8.  The  primary  characteristics 
of  MAXTAC  are  listed  in  Table  8-4. 


Figure  8-8:  MAXTAC  (deployed) 

Table  8-4:  Primary  Characteristics  of  MAXTAC 


Mass  (kg) 

262.5 

Height  of  bus  (cm) 

71 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 
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8.6  Variations  on  the  Baseline 

8.6.1  MIDTAC 

The  MIDTAC  alternative  is  exactly  the  same  as  the  MAXTAC  bus,  except  that  the 
bottom  level  is  shorter  due  to  the  smaller  propellant  tanks. 


Figure  8-9:  MIDTAC  (deployed) 

Table  8-5:  Primary  Characteristics  of  MIDTAC 


Mass  (kg) 

242.9 

Height  of  bus  (cm) 

68 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 
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8.6.2  LOWTAC 


The  LOWTAC  bus  is  also  the  same  as  MAXTAC,  but  with  an  even  shorter  bottom 


level. 


Figure  8-10:  LOWTAC  (deployed) 

Table  8-6:  Primary  Characteristics  of  LOWTAC 


Mass  (kg) 

215.7 

Height  of  bus  (cm) 

63 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 

8.6.3  MAXTAC-N 

In  the  next  three  alternatives,  the  layout  of  the  bottom  level  is  the  same  as  in  the 
previous  three  alternatives.  However,  there  is  no  SMASH.  In  fact,  since  the  removal  of 
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the  SMASH  space  leaves  only  a  few  components  on  the  top  level,  these  components  were 
relocated  onto  the  second  level  to  reduce  the  height  of  the  bus.  But  the  height  of  the 
second  level  was  increased  in  order  to  fit  all  of  components  within. 


Figure  8-11:  MAXTAC-N  (deployed) 

Table  8-7:  Primary  Characteristics  of  MAXTAC-N 


Mass  (kg) 

256.1 

Height  of  bus  (cm) 

69 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 
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8.6.4  MIDTAC-N 


Figure  8-12:  MIDTAC-N  (deployed) 

Table  8-8:  Primary  Characteristics  of  MIDTAC-N 


Mass  (kg) 

236.5 

Height  of  bus  (cm) 

66 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 
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8.6.5  LOWTAC-N 


Figure  8-13:  LOWTAC-N  (deployed) 

Table  8-9:  Primary  Characteristics  of  LOWTAC-N 


Mass  (kg) 

209.3 

Height  of  bus  (cm) 

61 

Average  Power  (watts) 

447 

Peak  Power  (watts) 

1000 

8.6.6  MIDTAC-23 

Finally,  a  23”  LV  interface  version  of  Modsat  was  created  simply  to  broaden  the 
solution  space  somewhat.  The  MIDTAC  platform  was  chosen,  although  any  of  the 
tactical  profiles  would  have  been  appropriate.  The  MIDTAC-23  bus  is  exactly  the  same 
as  the  MIDTAC  bus,  except  that  it  is  placed  higher  in  the  LV  due  to  the  interface. 
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Figure  8-14;  MIDTAC-23  (deployed) 

Table  8-10:  Primary  Characteristics  of  MIDTAC-23 


Mass  (kg) 

292.8 

Height  of  bus  (cm) 

95,7 

Average  Power  (watts) 

390 

Peak  Power  (watts) 

950 

8.7  Summary 

To  primary  characteristics  of  each  alternative  are  summarized  in ,  where 

1  =  MAXTAC 

2  =  MIDTAC 
3=LOWTAC 

4  =  MAXTAC-N 

5  -  MIDTAC-N 

6  =  LOWTAC-N 

7  =  MIDTAC-23 


Table  8-11:  Primary  Characteristics  of  All  Designs 


Characteristic 

1 

2 

3 

4 

5 

6 

7 

Mass  (kg) 

262.5 

242.9 

215.7 

256.1 

236.5 

209.3 

292.8 

Height  (cm) 

71 

68 

63 

69 

66 

61 

95.7 

Avg  Power  (W) 

447 

47 

447 

447 

447 

447 

390 

Peak  Power  (W) 

1000 

1000 

1000 

1000 

1000 

1000 

950 
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9.  System  Analysis 


This  section  discusses  the  evaluation  of  the  alternative  designs.  The  seven  design 


alternatives  are  evaluated  objective  by  objective.  For  objectives  with  natural  measures  of 


effectiveness,  the  performance  value  was  obtained  from  the  Modsat  model.  For  objectives 
with  attribute  scale  MOEs,  the  team  rated  the  performance  of  each  alternative  against  its 
attribute  scale. 

The  scoring  results  of  the  seven  alternatives  were  extremely  close,  differing  only  by 
0.0467  in  their  final  weighted  score.  This  is  not  surprising,  since  the  designs  are  not  vastly 


different  from  one  another. 


The  main  results  for  each  alternative  are  presented  below  in  Table  9-1  and  Table  9- 
2.  The  scores  listed  under  each  main  objective  in  Table  9-1  are  weighted  scores;  that  is, 
they  are  the  result  of  multiplying  the  utility  scores  for  a  given  objective  by  that  objective’s 
weight.  For  a  given  alternative,  the  sum  of  the  weighted  scores  for  each  main  objective 
yields  the  overall  utility  score  in  the  final  column. 


Table  9-1:  Weighted  Scores:  Standard  Weights 


0.1382 

0.3119 

0.1527 

0.1746 

0.2226 

Cost 

Responsiveness 

Risk 

Availability 

Utility 

Total 

MAXTAC 

0.07329 

0.2038 

0.1048 

0.1131 

0.1123 

0.6073 

MIDTAC 

0.09589 

0.1835 

0.1048 

0.1058 

0.1309 

0.6209 

LOWTAC 

0.1165 

0.1546 

0.1048 

0.06152 

0.151 

0.5884 

MAXTAC-N 

0.07378 

0.1962 

0.1054 

0.1169 

0.1134 

0.6057 

MIDTAC-N 

0.09354 

0.1763 

0.1054 

0.0947 

0.1296 

0.5995 

LOWTAC-N 

0.1098 

0.1469 

0.1054 

0.06507 

0.152 

0.5792 

MIDTAC-23 

0.09937 

0.18 

0.1048 

0.09085 

0.09914 

0.5742 
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The  final  scores  for  each  alternative  are  presented  in  again  in  Table  9-2,  where  the 
alternatives  have  been  ranked. 


Table  9-2:  Ranking  of  alternatives;  standard  weights 


1 

MIDTAC 

0.6209 

2 

MAXTAC 

0.6073 

3 

MAXTAC-N 

0.6057 

4 

MIDTAC-N 

0.5995 

5 

LOWTAC 

0.5884 

6 

LOWTAC-N 

0.5792 

7 

MIDTAC-23 

0.5742 

Considering  the  relative  scale  range  of  final  utility  values,  the  MIDTAC  design 
scores  significantly  higher  than  the  other  alternatives.  This  comparison  is  clearly  shown  in 
Figure  9-1  below. 


Standard  Weights 

0.5400  0.5600  0.5800  0.6000  0.6200  0.6400 

1 - ^ ^ 


Figure  9-1:  Performance  at  Standard  Weights 

Many  factors  combined  to  give  the  MIDTAC  alternative  the  highest  score.  In  the 

two  highest-weighted  objectives,  tactical  responsiveness  and  mission  utility,  the  MIDTAC 
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design  fared  the  best.  In  the  remaining  three  lower-weighted  objectives  MIDTAC 
obtained  average  scores.  The  MAXTAC  alternative  also  fared  well,  receiving  the  second 
highest  score.  This  is  attributed  to  MAXTAC’s  high  performance  rating  for  the  tactical 
responsiveness  objective,  which  is  the  highest-weighted  objective  in  this  study.  On  the 
opposite  end,  the  MIDT AC-23  alternative  scored  last,  scoring  average  in  four  objectives 
and  considerably  low  in  the  second  highest  weighted  objective,  mission  utility.  This  is  due 
to  its  usage  of  a  great  deal  more  of  the  launch  vehicle  fairing  volume,  as  well  as  the 
reduced  area  available  for  solar  arrays.  Although  MIDT  AC-23  was  last,  LOWTAC-N  was 
not  that  far  behind,  thus  reminding  the  team  that  scoring  well  in  higher  weighted 
objectives  is  the  key  to  a  better  overall  score. 
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10.  Decision  Making 


The  results  of  the  previous  chapter  revealed  that  the  MEDTAC  alternative  appears 
to  be  the  best  solution.  The  analysis  discussed  in  this  chapter  was  performed  in  order  to 
demonstrate  the  sensitivity  of  the  results  to  changes  in  the  objective  weights,  due  to 
shifting  environmental  factors. 

In  this  analysis,  environmental  scenarios  were  created  in  order  to  examine  the 
effect  of  changes  in  the  top-level  objective  weights.  In  each  scenario,  the  weight  of  one  of 
the  objectives  was  increased  to  correspond  with  a  certain  environmental  situation.  The 
weights  of  the  four  remaining  objectives  were  scaled  down  proportionally,  so  that  all  of 
the  weights  would  still  sum  to  one.  With  the  new  weights,  the  overall  utility  function  was 
performed  on  each  of  the  alternatives,  and  the  results  were  recorded.  In  some  cases,  an 
alternative  other  than  MIDTAC  received  the  highest  score.  The  scenarios  are: 

1 .  Cost  is  twice  as  important  as  its  original  priority. 

2.  Responsiveness  is  twice  as  important  as  its  original  priority. 

3.  Risk  is  twice  as  important  as  its  original  priority. 

4.  Availability  is  twice  as  important  as  its  original  priority. 

5.  Utility  is  twice  as  important  as  its  original  priority. 

6.  Cost  has  a  full  50%  of  the  sum  of  the  priority  weights  for  all  the  objectives  (cost 
weight  =  0.5). 

The  rankings  of  the  alternatives,  for  all  scenarios,  are  shown  below  in  Table  10-1 . 
The  MIDTAC  alternative  is  the  best  solution.  It  scored  in  the  top  three  in  every  scenario. 
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with  three  first  place  finishes,  two  second  place  finishes,  and  two  third  place  finishes.  The 
ranks  for  each  alternative,  summed  over  all  the  scenarios,  are  calculated  in  Table  10-2. 
These  results  further  portray  MIDTAC  as  the  superior  alternative.  It  is  a  well-rounded 
design  that  optimizes  the  tradeoffs  between  the  objectives.  Its  performance  in  both  the 
responsiveness  and  utility  objectives,  the  two  most  critical  attributes  of  the  study, 
contributes  to  its  high  score.  Note  that  MIDTAC  scores  well  in  both  the  responsiveness 
and  utility  scenarios,  while  the  other  alternatives  fail  to  do  so. 


Table  10-1:  Sensitivity  Analysis;  All  Environments 


Stan±n:l 

<Mx2 

l^sparEiveressx2 

RB<x2 

/ValaUI(tyx2 

Uilityx2 

SD%C« 

1 

MDn«C 

MOTfiC 

MW/C 

MDT/C 

MW/CN 

LQ/VT/C 

UW/C 

MWC 

LO/VTAC 

MW/CN 

MW/C 

MDT/C 

MDT/C 

LCWT/CN 

WmfiCH 

La/vr/cN 

MDT/C 

MW/CW 

MW/C 

IDWT/CN 

MDT/C 

MDTfiCH 

MDnaCN 

MDT/CN 

MDT/CN 

MDT/CN 

MDT/CN 

MDT/C23 

iONTPC 

MDT/OS 

MDT/CZ 

trvwc 

MDT/C23 

MW/CN 

MDT/CN 

LO/WCN 

MW/C 

LCWI/C 

LCWI/CN 

irvwc 

MW/C 

MW/CN 

■■ 

MDTfOZ 

MW/CN 

irwr/CN 

MDT/C23 

LOWT/CN 

MDT/C23 

MW/C 

Table  10-2:  Sum  of  Rankings  for  the  Alternatives 


Alternative 

Calculation 

Sum 

MAXTAC 

2+6+1 +2+3+6+7 

27 

MIDTAC 

1+1+3+1+2+2+3 

13 

LOWTAC 

5+2+6+5+6+1+1 

26 

MAXTAC-N 

3+7+2+3+1+5+6 

27 

MIDTAC-N 

4+4+44-4+4+4+5 

29 

LOWTAC-N 

6+3+7+6+7+3+2 

34 

MIDTAC-23 

7+5+5+7+5+7+4 

40 
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11.  Implementation 


This  section  is  intended  to  aid  the  CDM  in  the  implementation  of  the  results  of  the 
Modsat  study.  As  the  purpose  of  the  study  was  to  perform  high-level  systems 
engineering,  the  continuation  of  the  Modsat  program  will  require  much  more  detailed 
design  effort.  Moreover,  the  scope  of  this  study  was  limited  to  the  design  of  a  spacecraft 
bus.  Many  factors  and  functions  must  eventually  be  considered  and  designed  in  support  of 
Modsat  operations.  Recommendations  from  the  team  are  included  summarized  as  an 
overall  “concept  of  operations,”  and  are  discussed  below. 

11.1  Continued  Design  Effort 

The  systems  engineering  process  is  iterative  and  converging  in  nature.  The  scope 
of  each  iteration  of  the  design  process  depends  on  the  current  stage  within  the  life-cycle  of 
the  program.  As  the  life-cycle  progresses,  the  design  process  become  more  detailed. 
Eventually,  the  effort  converges  on  an  accepted  detailed  design. 

The  design  information  included  in  this  study  is  relevant  for  the  first  stage  of  the 
potential  life-cycle  of  Modsat.  In  this  stage,  sometimes  called  “concept  exploration,”  the 
systems  engineer  “identifies  all  reasonable  system  alternatives  that  may  satisfy  the  mission 
need  and  makes  recommendations...;  the  [CDM]  then  selects  those  alternatives  or 
concepts  which  meet  [the]  objectives”  (Systems  Engineering  Management  Guide,  1989:2- 
4).  If  the  Modsat  program  is  to  progress  further,  the  CDM  must  build  on  the  concepts 
and  recommendations  included  in  this  study. 
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In  the  next  iteration  of  the  design  process,  engineers  must  revisit  the  selection  of 
components  for  Modsat,  with  a  view  toward  optimizing  the  MIDTAC  design.  Interfaces 
must  be  designed,  at  the  subsystem  and  component  level.  In  particular,  command, 
telemetry,  power,  and  other  signal  flows  must  be  examined.  The  design  of  software  must 
begin,  within  the  context  of  the  modular  satellite  operating  system  recommended  by  this 
study.  Prototype  hardware  should  be  developed  to  demonstrate  the  functionality  of  some 
of  the  unique  aspects  of  Modsat,  such  as  its  cage  structure,  or  its  wrap-around  modular 
solar  array  assemblies. 

At  the  system  level,  the  mass  properties  (center  of  mass,  inertia  matrix,  etc.)  must 
be  carefully  examined  for  their  effect  on  stability  and  control.  Control  logic  should  be 
developed  to  model  the  attitude  control  function  of  Modsat.  Thermal  characteristics 
should  be  modeled  in  more  detail,  and  a  thermal  control  system  should  be  designed. 

The  continued  systems  engineering  effort  on  Modsat  must  incorporate  concurrent 
engineering,  wherein  current  engineering  efforts  reflect  consideration  of  manufacturing, 
testing,  logistics,  operational  support,  etc. 

The  items  mentioned  above  are  just  a  few  of  the  many  challenges  awaiting  the 
further  design  of  Modsat. 

11.2  Concept  of  Operations  (CONOPS) 

The  design  of  a  satellite  comprises  one  of  the  many  engineering  efforts  necessary 
for  the  operation  of  a  complete  space  system  architecture.  The  full  architecture 
encompasses  not  only  the  design  of  the  spacecraft  and  its  mission-specific  equipment,  but 
also  the  ground  segment  (equipment  and  personnel),  the  launch  segment  (equipment  and 
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personnel),  and  the  information/  communications  architecture  (user  interface  with  the 
system). 

11.2.1  Spacecraft  Architecture 

Implementation  of  the  small  tactical  satellite  design  (Tacsat)  should  take  into 
account  the  fact  that  the  “baseline”  design  is  generally  “over  powered”  (i.e.,  the  baseline 
design  provides  too  much  average  and  peak  power  levels  required  for  operation  of  most 
payloads).  With  this  consideration  in  mind,  application  of  an  alternative  design 
architecture  (other  than  the  “one  size  fits  all”  or  “baseline”  architecture)  becomes  desirable 
for  optimization  of  the  bus  to  the  wide  variety  of  mission  modules,  the  majority  of  which 
do  not  require  an  average  power  of  more  than  400  watts  or  a  peak  power  of  over  800 
watts.  The  payloads  which  may  require  these  high  average  and  peak  power  loads  are  those 
of  the  active  type  (LASERs  and  S  ARs),  whereas  passive  sensors  rarely  require  more  than 
100  watts  of  power  (peak  —  during  a  sensing  pass).  The  optimization  payoff  can  be 
measured  in  these  cases  with  more  available  volume  on  the  bus  (for  other  equipment)  and 
less  spacecraft  bus  mass  (increasing  available  mass  for  the  mission  module,  or  allowing  a 
different  orbit  configuration  —  including  a  higher  initial  altitude). 

Given  the  fact  that  the  solar  arrays  for  MIDTAC  are  already  a  modular  design 
tailorable  to  specific  needs,  and  the  fact  that  batteries  already  come  in  varying  sizes  for 
differing  capacity  requirements,  the  modular  option  should  be  the  architecture  chosen  for 
initial  implementation  of  the  Modsat.  Although  actual  operational  configurations  (stored 
and  ready  for  use)  for  the  Modsat  will  probably  mimic  the  ‘Tamily”  architecture  by 
including  “pre-integrated”  buses  already  tailored  for  either  the  low-power  or  high-power 
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mission  modules  (possibly  already  integrated  with  the  some  mission  modules,  as  well),  the 
modular  design  of  the  Modsat  provides  ultimate  reconfigurability  to  suit  changing  needs. 

11.2.2  Launch  Segment 

A  small  air-launched  system  provides  maximum  flexibility  for  the  choice  of  initial 
orbit  for  small  tactical  spacecraft,  because  of  the  fact  that  any  launch  azimuth  may  be 
chosen.  This  capability  also  minimizes  the  time  to  reach  a  chosen  target  (i.e.,  the  direct 
approach  will  be  the  fastest).  The  Pegasus  air  launched  booster  currently  represents  the 
only  launcher  in  this  category.  The  Taurus  booster,  while  not  air  launched,  is  more 
powerful  and  was  developed  specifically  for  rapid  deployment,  integration,  and  launch 
fi-om  unimproved  areas,  making  it  also  a  good  choice  for  the  launch  segment. 

The  force  structure  recommended  for  employment  of  small  tactical  satellite 
designs  consists  of  elements  firom  the  30th,  45th,  and  50th  Space  Wings  (30th,  45th,  and 
50th  SW)  working  in  concert.  The  1st  Tactical  Space  Launch  Squadron  (1st  TSLS), 
based  at  Vandenberg  AFB,  CA  (30th  SW)  would  be  responsible  for  westward  (retrograde 
and  Sun-synchronous)  launches  over  the  Pacific  Ocean  .  Similarly  the  2nd  TSLS  (45th 
SW,  Patrick  AFB,  FL)would  be  responsible  for  flights  east,  over  the  Atlantic.  The  19th 
Space  Operations  Squadron  (19th  SOPS),  based  at  Falcon  AFB,  CO  (50th  SW)  would 
have  responsibility  for  Modsat  launch  and  early  orbit  support,  Modsat  command  and 
control.  Tactical  Network  (TacNet)  maintenance  and  support,  and  manning  and  operation 
of  the  Consolidated  Tactical  Space  Control  Center  (CTSSC  --  see  below)  for  in-theatre 
operations  support.  Under  the  direction  of  a  Launch  Director,  each  of  the  Tactical  Space 
Launch  Squadrons  would  operate  B-52  or  other  {Pegasus)  carrier  aircraft.  In  addition,  a 
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spacecraft-to-mission  module  integration  (SMI)  crew,  a  spacecraft-to-launcher  integration 
(SLI)  crew,  a  loading  crew,  a  flight  and  launch  crew,  an  analysis  crew  and  a  launch 
(command  and  control)  crew  (under  the  direction  of  an  Operations  Director  at  the  19th 
SOPS  and  possibly  deployed  to  a  mobile  or  in-theatre  site),  would  accomplish  the 
integration,  loading,  flight  (to  launch  location  over  either  ocean),  launch,  and  early  orbit 
support  for  the  Modsat  mission. 


Tactical  Space  Launch  (East  Range/Atlantic) 


Figure  11-1:  Proposed  Organizational  Structure  for  Tactical  Spacelift 

(Eastern  Range/Atlantic) 

The  environment  for  the  design  study  also  assumes  that  a  ready  supply  of 
launchers,  satellite  buses,  and  mission  modules  is  on  hand  for  both  rapid  response 
situations  and  space  asset  replenishment.  Along  with  the  supplies  of  hardware,  other 
assumptions  include  ample  logistics  equipment  (transports,  “clean”  environments, 
maintenance  equipment,  special  tools,  etc.),  maintenance  personnel,  and  storage  facilities. 
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specific  personnel  for  each  crew  include  enlisted-grade  crew  members  and 
technicians/specialists  led  by  officer-grade  flight  commanders  and  deputies  (doubhng  as 
bus,  mission  module,  and  launch  vehicle  experts  for  their  respective  crews),  and  civihan 
engineering  and  analysis  personnel  (in-depth  engineering-intensive  positions  should  be 
made  civilian  contractor  or  GS  billets  to  retain  “corporate  knowledge”  on  the  systems). 


Tactical  Space  Launch  (West  Range/Pacific) 


Figure  11-2:  Proposed  Organizational  Structure  for  Tactical  Spacelift 

(Western  Range/Pacific) 


11.2.3  Ground  Segment  and  Information/Communications  Architecture 

The  main  ground  segment  for  the  small  tactical  satellite  should  be  an  X,  Ka,  or  Ku 
band  receiving  station,  perhaps  similar  to  the  Air  Force’s  “Eagle  Vision”  mobile,  in-theatre 
ground  station,  which  receives  mission  data  directly  fi-om  both  LAND  SAT  and  SPOT 
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satellites,  processes  the  imagery,  and  overlays  the  high-resolution  visible-region  imagery  of 
SPOT  with  the  multispectraJ  imagery  of  LANDS  AT.  Multispectral  imagery  products 
from  Eagle  Vision  have  received  rave  reviews  from  operational  and  theater  commanders 
(Veseley,  1996).  Initial  operations  testing  and/or  proof  of  concept  testing  (for  the  new 
tactical  satellites)  could  be  set  up  to  utilize  current  Eagle  Vision  equipment. 

This  central  receiving,  processing,  and  distribution  station,  known  as  the 
Consolidated  Tactical  Space  Control  Center  (CTSCC)  would  be  manned  and  operated  by 
crews  from  the  19th  SOPS  (50th  SW)  and  would  also  incorporate  an  S  band 
(SGLS/AFSCN  compatible)  commanding  capability  for  spacecraft  specific  commanding. 
CTSSC  terminal  stations  (including  a  permanent  CTSSC  at  Falcon  AFB,  CO)  would  be 
deployed  at  several  positions  on  the  Earth  to  ensure  fiill  support  for  any  and  every  theatre 
of  operations.  The  CTSSC  would  be  the  centerpiece  for  a  tactical  space  information 
network  into  which  tactical  users  would  input  requests  and  receive  information  products. 
User  requests/data  updates  would  be  transmitted  via  wireless  ethemet  protocols  (adapted 
from  currently  existing  internet  protocols)  carried  through  either  MILSTAR  MDR, 
Teledesic,  Iridium,  or  a  similar  high  data  rate,  global  communications  system. 

The  process  would  be  as  follows; 

1)  User  signs  on,  and  requests  are  encrypted  and  transmitted  from  a  laptop  or 
similar  small  computer  in  the  field  or  from  the  cockpit. 

2)  Requests  are  received,  authenticated,  and  prioritized  (set  by  the  Theatre  or 
Operational  Commander)  by  CTSCC  server. 
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3)  CTSCC  server  queries  (via  intelligent  agents)  the  types  and  availabilities  of 
appropriate  TACSATs  (based  on  the  type(s)  of  information  requested  by  the  user)  as  w^ell 
as  orbit  predictions  for  those  required  assets  which  are  available. 

4)  The  server  calculates  time  over  target,  time  to  receive  mission  data,  time  to 
process,  filter,  and  package,  and  time  to  transmit  requested  information  to  the  user. 

5)  If  the  requested  information  is  available,  the  CTSSC  server  replies  with  the 
product;  if  not  available,  the  CTSSC  server  replies  with  an  estimated  time  of  arrival  (ETA) 
for  the  product,  based  on  its  calculations  in  4). 

These  tasks  and  the  artificially  intelligent  systems  and  software  required  to 
accomplish  them  are  possible  with  current  computer  and  software  technology  and  may  be 
made  functionally  “modular”  (in  both  hardware  and  software  design)  to  ensure  future 
upgrade  capability.  To  make  this  system  work  well  for  an  easily  estimable  “many”  users, 
the  communications  systems  employed  and/or  utilized  will  have  to  support  the  necessary 
bandwidth  to  successfully  support  the  tactical  user  in  a  timely  fashion;  otherwise,  the 
CTSCC’s  tactical  support  capability  will  be  degraded.  Centralizing  the  processing  power 
of  this  tactical  space  information  system  in  the  CTSSC  (as  opposed  to  performing  the 
data-to-information  processing  on  the  satellites)  allows  more  processing  power  to  be 
utilized,  allows  easy  upgrades  to  software,  allows  simpler  troubleshooting  of  software, 
retains  the  satellites’  simplicity  ~  both  from  the  hardware  and  the  software  standpoints, 
retains  central  control  authority  for  information  dissemination,  promotes  optimal  tasking 
of  resources  (again,  due  to  centralized  control  and  prioritization),  simplifies 
communications  to  and  from  the  satellites  (multiple  channels  are  unnecessary),  and  allows 
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future  upgrades  to  the  overall  architecture  to  perhaps  “evolve”  into  a  system  which 
incorporates  more  “on  board”  processing  and  direct  downlinking  to  users.  Having  the 
information  processed  by  the  ground  segment  is  the  simpler,  more  powerftil  choice  for 
current  technology. 


Tactical  Space  Launch  (Command  and  Control) 


50th  SW 


An  alternative  to  the  (assumed  baseline)  ground-based  CTSSC  would  be  a 
dedicated  command  and  control  aircraft,  or  the  CTSCC  could  be  palletized  and  flown 
aboard  a  C- 17  or  C-5,  further  enhancing  its  mobility. 
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12.  Future  Technologies  and  Continuing  Investigations 


The  preliminary  design  for  a  small  tactical  spacecraft  bus  provides  a  solid 
foundation  for  further  investigations  as  well  as  continued  expansion  of  the  Modsat 
computer  design  model.  Design  efforts  generated  a  tremendous  amount  of  information  in 
addition  to  producing  the  Modsat  computer-based  design  tool  and  a  design  for  a  standard, 
tactically  applicable  satellite  bus.  Much  of  this  information  was  not  included  within  the 
formal  system  process  either  due  to  the  planning  horizon  for  the  proposed  design  (five 
years)  or  because  of  the  “nonessential”  nature  of  much  of  the  information  (to  the  design). 
These  topics  nonetheless  sparked  many  discussions  during  meetings  and  comprise  an 
interesting  set  of  ideas  and  technologies  on  which  to  base  a  possible  future  design  study 
(or  design  studies).  The  design  process  also  generated  several  concepts  for  future 
scientific  research,  operational  analysis,  and  system  design. 

12.1  Modsat  Computer  Model  Enhancements 

The  Modsat  computer  model,  which  was  developed  to  aid  in  the  design  and 
evaluation  of  small  tactical  satellite  designs,  provides  a  foundation  for  further 
enhancements,  additions,  refinements,  and  detail.  Modsat’s  coding,  though  large  in  scope, 
is  rather  simple  in  style,  and  it  is  thoroughly  documented  internally.  Future  additions  or 
modifications  to  the  code  may  include: 

•  more  integration  of  orbit  analysis  features 

•  additional  mission  module  configurations  and/or  types 

•  additional  cost  models 
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•  more  detailed  component  or  subsystem  modeling 

•  larger  libraries  of  selectable  components 

•  future  technology  modeling 

•  more  in-depth  launch  vehicle  modeling  and/or  design 

•  more  detailed  interface  modeling 

Detailed  discussion  of  the  individual  sections  and  functions  (background,  scope, 
functionality,  limitation(s),  and  future  feature  suggestions)  of  the  Modsat  computer  model 
can  be  found  in  Volume  III  in  the  Modeling  section. 

12.2  Constellation  Design 

Multiple  satellites,  carrying  active  sensors,  may  in  the  future  be  employed  in 
concert  as  an  “array”  of  sensors.  The  operational  challenge  of  such  a  constellation  can  be 
solved  either  by  maintaining  relative  satellite  positions  and  attitudes  to  within  close 
tolerances  (within  a  few  millimeters),  or  by  maintaining  extremely  accurate  position  and 
orientation  knowledge  (to  within  a  few  millimeters).  The  second  solution  is  the  more 
feasible  of  the  two,  because  satellites  equipped  with  multiple  GPS  receivers  can  produce 
these  knowledge  products  to  within  the  accuracy  necessary  (NASA,  1995:  sec.7,  p.3), 
and  with  this  knowledge  ground-based  computer  processing  can  correct  for  discrepancies 
in  received  signals  (between  spacecraft).  A  constellation  of  this  type  would  have  the 
potential  of  creating  an  extremely  large  synthesized  aperture;  however,  the  processing 
power  required  for  a  constellation  of  more  than  two  or  three  satellites  would  no  doubt  be 
tremendous  and  possibly  prohibitive  with  current  capabilities. 
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Further  analysis  may  be  performed  regarding  the  types  of  orbits  employed  for 
tactical  satellites.  The  primary  orbit  chosen  as  the  baseline  for  this  study  was  a  Sun- 
synchronous  orbit  at  an  altitude  of  350  kilometers.  This  orbit  type  has  definite  advantages 
for  remote  sensing  and  Earth  resources  missions;  however,  other  orbits  exist  which  may 
provide  greater  utility  for  specific  missions.  The  highly  eccentric  Molniya  orbits  provide 
long  dwell  time,  but  at  a  geosynchronous  altitude  during  that  dwell  time;  this  orbit  type 
may  be  useful  for  tactically-applied  communications  satellites  designed  for  short  mission 
durations.  “Walker”  orbit  parameters  (Wertz,  1992:  189-192)  provide  a  useful  method 
for  construction  of  constellations  with  specific  coverage  goals  in  mind.  One  example  is 
that  of  multiple  satellites  being  “staggered”  in  one  or  more  specific  orbital  planes  such 
that,  as  one  satellite  “sets  “  on  a  target,  the  next  satellite  in  line  comes  into  view. 
Constellation  design  and  optimization  is  a  complex  art.  Space  planners  and  designers  may 
wish  to  examine  the  advantages  and  disadvantages  of  the  coverages,  dwell  times,  revisit 
times,  and  environmental  stresses  associated  with  various  orbit  types. 

12.3  Logistics  and  Operations 

There  are  logistical  challenges  involved  with  the  transport,  storage,  and 
maintenance  of  a  (large)  supply  of  not  only  tactical  satellite  buses,  but  also  mission 
modules  (of  multiple  types),  small  launch  vehicles,  and  support  equipment  (and  support 
aircraft  in  the  case  of  air-launched  spacelift).  Another  possible  (albeit  novel)  logistical 
and/or  operational  strategy  study  would  be  to  investigate  possible  ways  of  recovering  the 
satellites  ~  either  by  retrieval  or  reentry  —  and  gauge  their  feasibility  and  utility  in  a 
tactical  environment  constrained  by  costs  and  the  increasing  desire  to  reuse  hardware. 
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Further  analysis  may  be  performed  on  the  actual  missions  and/or  applications  for 
the  tactical  satellite,  not  only  on  the  sensing  and  support  (of  terrestrial  forces)  aspect  of 
space  based  platforms,  but  also  on  the  possible  force  application  roles  of  such  platforms. 

The  air-launched  ICBM  test  program  of  the  1970s  and  the  current  “ALT- Air” 
program  sponsored  by  the  Ballistic  Missile  Defense  Organization  (BMDO)  have 
demonstrated  the  feasibility  of  a  carrier  aircraft-based,  palletized  launch  scheme.  In  this 
scheme,  a  launch  vehicle  is  transported  inside  the  carrier  aircraft,  deployed  off  of  an  aft- 
ejected,  parachute-assisted  pallet  with  a  stabilized  drogue  chute,  and  ignited.  This  launch 
scheme  could  be  applied  to  a  new  launch  system  specifically  designed  for  this  purpose. 
Investigations  could  include  adaptation  of  an  existing  system  to  this  scheme  (like  the 
ICBM  tests  of  twenty  years  ago).  This  transport  environment  has  the  potential  of 
providing  a  much  more  benign  environment  (vibrational  and  thermal)  for  the  launcher  and 
spacecraft  payload,  as  well  as  possibly  supporting  a  “clean”  environment  (e.g.,  a  “clean 
tent”  such  as  used  by  the  Pegasus)  inside  the  aircraft  itself  during  transport  --  due  to  the 
fact  that  the  interior  of  the  aircraft  is  environmentally  controllable.  Additionally,  regular 
loading  crews  would  need  no  special  training  for  handling  the  rocket  pallet,  since  the  pallet 
would  be  the  same  as  any  other  pallet  fitted  for  that  particular  aircraft. 

12.4  Mission  Modules 

This  design  study  focuses  specific  design  determination  efforts  upon  only  the 
satellite  bus;  however,  due  to  the  particular  design  paradigm,  the  primary  design  standards 
imposed  upon  the  mission  module  designer  may  be  enumerated.  Though  the  standard 
small  tactical  spacecraft  bus  will  provide  support  for  the  mission  modules,  mission  module 
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designers  will  be  required  to  design  “to  the  bus”,  as  opposed  to  the  bus  being  built  for  the 
specific  payload  equipment.  Analogous  to  the  interface  requirements  to  which  underwing 
stores  on  a  fighter  must  be  designed,  the  mission  modules  must  conform  to  certain 
electrical,  mechanical,  data  protocol,  telemetric,  and  software  interfaces  incorporated  into 
the  bus  design.  Many  of  the  specifications  for  these  interfaces  will  be  provided  by  the 
SPIG  (see  Tradeoffs). 

Table  12-1  summarizes  the  generally  specified  requirements  for  the  design  of  the 
various  mission  modules. 


Table  12-1:  Mission  Module  Design  Requirements 


Design  Consideration 

Mission  Module  Design  Requirement 

Mission  Scope 

single-sensor  type;  narrow  mission 
specification 

Mission  Mass 

under  120  kg 

Mission  Power 

average  under  320  W 
peak  under  820  W 

Mission  Volume 

under  0.6  m 

High  Data  Rate  Downlink 

must  be  integral  if  greater  than  SGLS  rate  is 
desired 

Data  Storage  Capacity 

must  be  integral  if  greater  than  2Gbytes  is 
desired  (unless  storage  is  modular) 

Mechanical  Interface 

conform  to  SPIG 

Electrical  Interface 

28  V  regulated  bus  standard;  conform  to 
SPIG 

Telemetry/Software  Interface 

compatibility  with  bus  standard  formatting; 
specialized  mission  software  extensions  (to 
SOS)  must  be  integral 

Thermal  Environment 

isolation  from  bus;  specialized  mission 
equipment  integral 

Design  Focus 

tactical;  minimize  testing  time;  minimize 
warmup  time 
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The  mission  modules  modeled  in  the  Modsat  computer  model  are  necessarily 
“generic”  in  nature  to  provide  both  flexibility  in  design  evaluation  and  a  foundation  on 
which  more  specific  types  may  be  modeled  in  both  the  current  version  and  in  future 
versions. 

Future  operational  analysis  may  focus  on  optimizing  the  functionality  of  different 
types  of  mission  modules  and  putting  together  the  most  tactically  useful,  easily  storable, 
quickly  integratable,  and  technically  feasible  combination  of  mission  modules  for  tactical 
space  missions. 

A  specific  mission  module  for  performance  of  a  “LASER  designator  from  space” 
role  was  not  specifically  addressed  by  the  system  design  study,  due  to  the  number  and 
variability  of  the  many  factors  involved  in  the  mission  analysis  for  such  a  mission  module, 
as  well  as  the  “experimental”  nature  of  any  such  mission  module  if  constructed  with 
current  technology.  A  mission  module  of  this  type  may  be  roughly  modeled,  however, 
with  the  LASER/LID AR  mission  module  tools  incorporated  in  the  Modsat  computer 
model.  A  future  trade  study  on  the  design  of  such  a  mission  module  would  require 
analysis  of  1)  illumination  efficiency,  power,  and  wavelength(s);  2)  target 
reflectivity/signature  in  the  given  wavelength(s);  3)  detector  positioning  (azimuth, 
elevation,  and  altitude),  sensitivity  in  the  given  wavelength(s),  field  of  view,  signal  to  noise 
ratio,  and  velocity;  and  4)  possible  adversarial  countermeasures  and  spoofing.  Finally, 
sizing  of  the  mission  module’s  volume,  mass,  and  power  requirements  may  or  may  not 
make  this  application  feasible  for  a  small  satellite  application.  Of  course,  a  primary  goal  of 
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this  type  of  research  would  be  the  determination  of  “payoffs”  in  costs,  manpower, 
equipment,  capability,  and  responsiveness  that  this  type  of  system  may  or  may  not 
achieve. 

A  similarly  experimental  application  (and  as  worthy  or  more  worthy  of  further 
investigation)  being  developed  for  LASERs  is  that  of  extremely  high  data  rate 
communications  systems.  Many  of  the  tradeoff  factors  and  design  considerations  involved 
in  the  design  of  a  LASER  designation  system  are  applicable  to  the  design  of  a  LASER- 
based  communications  system  (i.e.,  power,  sensitivity,  positioning,  signal  to  noise  ratio, 
field  of  view,  and ,  of  course,  atmospheric  attenuation). 

12.4.1  Small  Satellite  Technologies  “On  the  Horizon” 

Many  novel  and  exciting  (as  well  as  veiy  technically  challenging)  technologies 
promise  to  change  the  face  of  satellite  design  in  the  not  so  distant  future.  All  of  these 
technologies  are  expected  to  be  developed  within  the  next  ten  years. 

Flywheel  Technology  --  Flywheels  provide  power  and  momentum  storage  through  the 
utilization  of  kinetic  energy  storage.  These  structures  represent  potentially  lighter  weight 
and  higher  capacity  than  chemical-based  batteries,  with  the  added  functionality  of  naturally 
stabilizing  a  spacecraft  in  (as  do  traditional  momentum  wheels).  This  “functional  density” 
(in  which  one  component  performs  more  than  one  function)  is  a  popular  theme  for  small 
satellite  design,  and  is  already  evident  in  most  designs  for  spacecraft  CPUs,  as 
multifunctional  microprocessors  are  becoming  the  norm  for  small  satellites  (Hively,  1996). 
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Lithium-Ion  Batteries  —  These  batteries  provide  vastly  higher  capacity  than  traditional 
and  current  technology  chemical  batteries  (see  Vol  II,  Tradeoffs,  Electrical  Power 
Subsystem). 

Inflatable  Structures  —  This  technology  will  allow  smaller  spacecraft  buses  to  support 
much  larger,  more  capable  active  sensors,  such  as  those  required  for  synthetic  aperture 
RADAR.  Current  efforts  are  underway  at  NASA  to  produce  electronically  steerable, 
high-resolution  RADARs  for  launch  on  small  vehicles,  but  inflatable  structure  technology 
would  significantly  reduce  payload  mass  and  required  payload  fairing  volume  (scaling 
down  required  volume  from  “cubic  feet”  to  volumes  on  the  order  of  “cubic  inches”), 
thereby  freeing  up  space  on  the  booster  for  other  experiments  (on  the  spacecraft)  or  other 
vehicles  (within  the  fairing)  (NASA,  1995). 

Global  Positioning  System  (GPS)  Applications  -  GPS  promises  to  provide  much  better 
accuracy  and  more  timely  and  autonomous  orbital  position  prediction  and  tracking  than 
current  methods  of  ground  tracking.  Utilization  of  GPS  will  fi-ee  up  much  of  the 
overtaxed  Air  Force  Satellite  Control  Network  (AFSCN)  fi'om  mundane  “tracking” 
supports  for  the  new  vehicles  equipped  with  GPS  receivers.  Experiments  in  the  future  will 
also  include  single  vehicles  equipped  with  multiple  receivers,  testing  GPS  capability  to 
determine  spacecraft  attitude.  If  this  application  proves  functional,  it  will  reheve  much  of 
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the  attitude  control  system  requirements  for  attitude  knowledge  sensors,  thereby  further 
reducing  spacecraft  mass. 

“Toroidal”  Propellant  Tank  —  This  propellant  tank  design  was  home  out  of  system 
synthesis  efforts  as  a  theoretically  more  efficient  propellant  tank  packaging  scheme, 
optimizing  available  volume  within  a  spacecraft. 

Fourier  Transform  Hyperspectral  Imaging  —  This  imaging  package  under  investigation 
at  Phillips  Lab  represents  a  new  paradigm  in  multispectral  imaging  --  spectral  resolution 
approaching  that  of  gas  chromatography  and/or  spectrometers  (i.e.,  evolution  toward  a 
“continuous  spectral  imaging  system”  paradigm)  through  the  usage  of  Fourier  Transform 
systems  for  spectral  separation.  Improved  spectral  resolution,  lighter  instrument  weight, 
and  more  efficient  transmission  (than  the  current  “best”  method  of  dispersion  gratings)  is 
achieved  through  Fourier  Transform  separation  (Hagan,  1996;Otten  and  others,  1995). 

Pulsed  plasma  thrusters  --  These  and  other  low-thrust,  high  specific  impulse,  non 
chemical  propulsion  systems  will  provide  lower  thrust,  but  more  total  delta- velocity 
capability  (per  unit  mass)  over  the  life  of  the  satellite  than  chemical  thrusters  (Hagan, 
1996).  Experiments  utilizing  PPTs  are  planned  for  the  Phillips  Lab’s  MightySat  program. 

Ka-Band  Transmitter  Experiment  ~  Another  experimental  payload  project  for  the 
Phillips  Lab  MightySat  program,  this  phased  array  communications  package  will  provide 


testing  and  validation  of  technologies  expected  to  reduce  the  mass,  moving  parts,  and 
spacecraft  attitude  adjustments  required  to  track  a  signal  from  a  communications  ground 
station.  It  will  also  study  high  data  rate  modulation  techniques. 

Small  liquid-fueled  booster  —  Solid  rocket  motors  (SRMs),  while  inexpensive  and  easily 
adaptable  to  small  launch  systems,  are  heavy,  toxic,  fragile,  less  flexible,  and  less  reliable 
(in  general)  than  liquid  rocket-based  launch  systems.  Phillips  Lab  and  other  research 
organizations  (as  well  as  some  sectors  in  industry)  are  developing  prototypes  of  a 
simplified  “blow  down”  pressurized  liquid-fueled  rocket  for  use  as  a  small  launch  system 
(Warner,  1996;  Worden,  1996).  This  system  incorporates  propellant,  oxidizer,  and  an 
inert  pressurant  (helium)  to  inject  the  propellant  and  oxidizer  into  the  combustion 
chamber.  This  system  can  be  built  with  few  or  no  moving  parts,  and,  by  virtue  of  being 
“throttleable”  the  system’s  performance  can  be  fine-tuned  and/or  trimmed  during  flight  (as 
opposed  to  a  SRM,  which  may  be  vectorable,  but  not  dynamically  thrust-variable  while  in¬ 
flight),  thereby  increasing  initial  orbit  accuracy.  These  types  of  simple,  small  rockets  could 
eventually  replace  SRMs  in  most  applications  (e  g.,  as  an  air-launched  system). 
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13.  Conclusions 


Although  the  individual  products  and  ideas  generated  throughout  this  study  may 
be  individually  worthy  of  merit,  the  three  important  results  of  this  study  fiilly  characterize 
the  synergism  of  the  effort.  The  utilization  of  an  adaptable  (i.e.,  specific  to  the  task  at  hand 
and  the  circumstances  of  the  environment)  System  Design  Process  made  all  of  the  effort 
possible  and  productive.  The  generation  of  a  feasible,  value-added,  “clean-sheet” 
MEDTAC  design  for  a  small  tactical  satellite  bus  provides  a  basis  for  further  development 
of  “tactical  space”  or  “TacSpace”  concepts.  The  construction  of  a  generic  and  modular 
(i.e.,  robust,  modifiable,  expandable)  Modsat  Computer  Design  Model,  though  the 
greatest  challenge  of  the  effort,  provides  a  usefiil,  valuable  design  platform  for  use  by  both 
future  researchers  and  students. 

13.1  Modsat  Model 

The  construction  effort  involved  with  the  development  of  a  fully  integrated 
computer  design  and  analysis  tool  for  small  satellites  comprised  a  systematic  design 
process  in  itself  As  with  the  individual  subsystem  component  choices,  individual 
subsystem  modeling  sections  formed  along  baseline  component  characteristics  determined 
by  the  subsystem  trade  studies.  The  value  system  determined  by  the  team  formed  the 
basis  of  the  analysis  section  of  the  model.  The  Modsat  modeling  software  package 
provides  for  analysis  of  physical  characteristics,  mission  performance,  and  overall  costs. 

The  Modsat  model  provides  a  foundation  for  further  analysis  efforts.  The 
underlying  functions  of  the  software  may  be  modified  or  expanded  according  to  a 
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particular  user’s  requirements  and  objectives.  A  vast  array  of  different  sizes,  shapes, 
materials,  and  other  characteristics  may  be  modeled,  based  upon  user  input.  The  initial 
version  of  the  model  provides  estimations  which  may  be  updated  (through  modification  of 
the  underlying  code)  with  evolutions  in  space  technology  or  changes  in  design  philosophy. 
Aside  from  these  more  esoteric  considerations,  the  software,  of  course,  may  be  used  for 
the  analysis  of  small  satellite  designs  other  than  those  analyzed  in  this  preliminary  study. 
Using  differently  modeled  components  and  differently  modeled  value  systems,  the  Modsat 
modeling  tool  has  the  capability  to  produce  a  wide  range  of  possible  designs. 

13.2  Design  Concept 

The  MIDTAC  spacecraft  bus  provides  a  generic  design  that  may  be  further 
developed  for  specific  applications  or  more  completely  engineered  for  actual  production. 
The  MIDTAC  bus,  as  a  complete  system,  has  been  designed  to  the  extent  that  feasible  bus 
enhancements  may  be  easily  explored  and  developed.  As  recommended  by  this  system 
study,  the  expected  implementation  of  the  MIDTAC  bus  incorporates  a  modular  power 
generation  system  to  provide  tailoring  of  power  levels  required  by  various  mission 
modules.  The  actual  design  may  also  incorporate  other  modular  and/or  tailorable 
components  or  subsystems. 

The  next  step  in  the  development  of  this  bus  design  should  be  an  engineering  study 
of  the  interfaces  required  to  integrate  all  of  the  individual  satellite  subsystems  and 
components.  While  the  MIDTAC  design  includes  physical  characteristics  and  a  “working 
concept”,  this  design  is  only  the  first  step  in  development  process;  it  comprises  the  results 
of  an  initial  “concept  exploration”  phase  for  a  new  space  system.  Concurrent  engineering 
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studies  concerning  manufacturing,  integration,  and  testing  for  the  MIDTAC  design  must 
also  be  accomplished.  Finally,  mission  modules  must  be  designed  for  flight  testing  and 
operation  on  the  MIDTAC  bus. 


Figure  13-1:  MIDTAC  Bus  and  Vital  Statistics 


Physical  Characteristics/Capabilities; 

Mass:  243  kg 

Available  Power  (average/peak):  319/827  W  (tailorable  to  mission) 

Available  Mission  Mass:  75  kg  (350  km,  sun-synch)/200  kg  (350  km,  28.5  deg) 
Available  Mission  Volume:  0,7855  m^ 

Pointing  Accuracy/ Attitude  Knowledge:  0.1  deg/0.05  deg  (nominal) 

Data  Storage:  Modular  2Gbyte  SSDR  (tailorable  to  mission) 

Delta-velocity  Capacity:  300m/s 

Subsystem  Features: 

Mission  Modules:  SPIG  interfaces,  EO,  MSI,  LASER/LID AR,  SAR 

ADCS:  three-axis  stabilized,  reaction  wheels  (4),  star  sensor.  Earth  sensor,  IMU 

Propulsion:  monopropellant  thrusters  (6),  cylindrical  tanks  (4) 

Structural:  octagonal  “cage”  structure,  “3-level”  shelf  system,  SMASH  option 
EPS:  NiH2  batteries,  modular  GaAs  solar  arrays,  decentralized  distribution 
TT&C:  SGLS  compatible,  1024  kbps  nominal  downlink.  Satellite  Operating  System 
(SOS),  TCP/IP  protocol 
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The  MIDTAC  design  ultimately  provides  a  solution  to  one  portion  of  a  much 
greater,  underlying  problem  facing  modem  space  efforts  (military,  scientific,  and 
commercial).  More  responsive,  less  expensive,  and  more  efficient  access  to  space  is  an 
issue  which  requires  new  and  innovative  approaches  to  not  only  spacecraft  design  (the 
focus  of  this  study),  but  also  spacelift,  command  and  control,  and  information  processing 
and  distribution.  In  addition  to  providing  a  tactically  applicable  satellite  bus,  the  MIDTAC 
design  will  provide  the  Air  Force  with  ready-to-fly  space  research  platforms.  The  space 
environment  will  be  more  accessible  to  technology  demonstrations,  developmental 
payloads,  and  other  space  experiments  by  having  these  standard  buses  (with  standard 
mission  interfaces)  readily  available.  The  MIDTAC  design  essentially  provides  to  the  Air 
Force  a  standard  vehicle  -  putting  the  “horse”  before  the  “cart”  -  on  which  it  may  more 
readily  and  effectively  conduct  space  operations  and  technology  development.  MIDTAC 
will  allow  the  Air  Force  to  more  quickly  accumulate  valuable  “spaceflight  time”  and 
experience.  Only  with  increased  “hands  on”  experience  in  spaceflight  and  space 
operations  will  the  Air  Force  fully  evolve  into  its  role  as  a  “Spacepower”.  MIDTAC 
provides  the  means  to  that  end. 

13.3  System  Process  and  Beyond 

The  start  of  the  system  design  began  necessarily  with  a  generalized,  high-level 
treatment  of  the  problem  posed  by  the  CDM:  the  generation  of  a  “clean  sheet”  tactical 
satellite  design  for  use  as  a  “multirole”  satellite,  capable  of  supporting  a  wide  variety  of 
payload  (mission  module)  types.  This  design  should  be  easily  and  inexpensively  produced 
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for  the  Air  Force,  smoothly  integrated  by  a  primarily  “blue  suit”  special  weapons  crew, 
and  quickly  launched  for  either  quick-response  or  asset-replenishment  missions.  Initial 
considerations  involved  the  various  high-level  (nonspecific  components)  design  and 
implementation  approaches  to  this  problem;  further  efforts  evolved  to  focus  efforts  on 
creating  the  “baseline”  or  “point  design”  with  which  the  original  design  approaches  could 
be  considered  in  combination.  This  combination  of  design  (the  MIDTAC)  and  approach 
(i.e.,  modularized  components)  produced  an  optimal  solution. 

The  (satellite)  fimctional  division  of  effort,  in  addition  to  the  assignment  of  system 
process  responsibilities  among  team  members,  was  key  to  success.  The  convergence  of 
the  overall  design  and  the  development  of  the  Modsat  modeling  software  required  expert 
knowledge  of  individual  subsystems.  Consideration  of  generic  remote  sensing  mission 
modules  provided  baseline  requirements  for  the  bus  design.  The  system,  reliability,  and 
subsystem  trade  studies  narrowed  the  solution  space  for  the  bus  design  to  a  point  where 
baseline  designs  could  be  generated.  Effective  coordination  of  the  overall  system  design 
effort  required  central  coordination  for  each  of  the  system  process  phases:  problem 
definition,  value  system  design,  system  and  subsystem  design  tradeoffs,  system  synthesis, 
modeling  and  optimization,  decision  making,  and  implementation.  This  approach  not  only 
allowed  the  systematic  construction  of  a  robust  design  and  analysis  tool,  but  also  the 
synthesis  of  seven  fully  integrated,  fully  characterized  designs  which  could  then  be 
thoroughly  analyzed  and  evaluated. 

The  basic  validity  and  robustness  of  the  process  may  be  fully  and  objectively 
realized  when  considering  the  role  of  the  CDM.  Other  than  an  initial,  broad  design 
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philosophy,  the  CDM  provided  little  input.  Faced  with  this  “ill-posed”  problem,  the  team 
created  a  process  which  allowed  a  “natural”  evolution  of  objectives,  focusing  of  efforts, 
convergence  of  designs,  and,  most  importantly,  solidification  of  goals.  These  goals 
included  the  construction  of  the  Modsat  model  and  the  development  of  a  “baseline” 
design.  Modification  of  either  the  assumptions  of  the  problem  definition  or  the  value 
system  (based  upon  the  preferences  of  the  CDM)  may  yield  vastly  different  results.  This 
allows  the  adaptability  of  the  process  to  other  space  system  design  projects. 

This  process  is  unique,  innovative,  and  goes  beyond  traditional  system  and  satellite 
design  approaches.  Although  Hall’s  Process  and  the  SMAD  process  were  used  as 
references  and  process  “baselines”,  these  approaches  ultimately  proved  unsuitable,  due  to 
the  unusual  design  paradigm  assumed  by  the  team.  The  “mission  module”  is  a  concept 
wherein  the  payload  equipment  must  be  integrated  to  the  satellite  bus  and  conform  to  bus- 
constrained  design  parameters.  This  is  a  design  paradigm  unpopular  within  the  aerospace 
industry,  and  runs  contrary  to  the  traditional  approaches  to  spacecraft  design  prescribed  by 
the  SMAD  process.  Considering  the  stagnation  of  space  efforts  and  the  lack  of  relief  fi'om 
the  high  cost  and  low  availabiUty  of  space  access,  the  pursuit  of  an  alternative  spacecraft 
design  paradigm  was  reasonable,  if  not  necessary.  The  team  required,  and  ultimately 
developed,  a  process  that  was  less  dependent  upon  mission-derived  design  specifications 
and  allowed  more  design  fireedom  to  consider  the  Avide  range  of  spacecraft  design 
possibilities. 

Finally,  the  process  is,  unlike  the  SMAD  process,  synergistic  in  approach,  and  it 
epitomizes  the  concept  of  “functional  density,”  wherein  the  process  served  many  purposes 
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simultaneously.  The  research  involved  in  the  subsystem  trade  studies  produced  the 
component  data  for  use  in  the  modeling  tool,  narrowed  the  scope  of  subsystem  design 
choices,  and  refined  the  design  objectives  and  value  system.  The  iterative  process  of  the 
synthesis  of  individual  designs  solidified  design  alternatives  and  also  refined  the  model. 
The  ultimate  results  of  the  development  and  application  of  this  process  resonate  beyond 
the  generation  of  the  MEDTAC  design  and  the  development  of  the  Modsat  model.  The 
results  of  this  study  show  that,  as  a  solution  to  the  “space  access”  problem,  an  alternative 
to  the  current  design  paradigm  (i.e.,  “generic”  versus  “specific”)  is  not  only  feasible  but 
desirable.  This  study,  its  process,  and  its  products  set  the  standards  of  creativity, 
innovativeness,  adaptability,  and  robustness  for  future  spacecraft  design  efforts.  The 
Modsat  design  team  has  set  the  bold  example  that  others  will  follow. 


153 


Bibliography 


1.  The  Aerospace  Corporation.  Consolidated  Mission  Architecture.  The  Aerospace 
Corporation,  El  Segundo,  California,  Oct-93. 

2.  Aerospace  Division  Olin  Defense  System  Group.  Hydrazine  Handbook.  Redmond,  WA: 
Rocket  Research  Company,  1995. 

3.  Aerospace  Systems  Division,  1996;  http://www.ball.com/corporate/haerobas.html. 

4.  American  Institute  of  Aeronautics  and  Astronautics,  Inc.,  Phillips  Laboratory  Homepage, 
1996:  http://www.plk.a£mil. 

5.  Arizona  State  Univ.  Statement  of  Work  for  the  MightvSat  Phase  n  Program  /Revision  41 
Philhps  Laboratory,  Kirtland  AFB,  New  Mexico,  3 1  -Mar-96. 

6.  Asker,  James  R.  “Ball  Drops  Pegasus  Plan,  Selects  Lockheed  Launcher,”  Aviation  Week 
&  Space  Technology.  :  58  (December  6, 1993). 

7.  Asker,  James  R.  “  Quick  Response  Key  to  Next  U.S.  Launcher,”  Aviation  Week  &  Space 
Technology,  :  44-46  (September  28, 1992). 

8.  Asker,  James  R.  “  Speedy  Fix  Eyed  For  Pegasus  XL,”  Aviation  Week  &  Space 
Technology.  :  21-22  (July  3, 1995). 

9.  Athey,  Thomas  H.  Systematic  Systems  Approach:  An  integrated  Method  for  Solving 
System  Problems.  New  Jersey:  Prentice-Hall,  1982. 

10.  Bate,  Roger  R,  Mueller,  Donald  D.,  and  White,  Jerry  E.  Fundamentals  of  Astrodvnamics. 
New  York:  Dover  Publications,  1971. 

1 1 .  Bearden,  David,  and  others.  “Cost  Modeling,”  Reducing  Space  Mission  Cost.  Ed.  Wertz, 
James,  and  Larson,  Wiley.  Torrance,  CA:  Microcosm,  Inc.,  1996. 


154 


12.  Beer,  Ferdinand  P.  and  Johnston,  E.  Russell.  Aircraft  Structures.  USA;  McGraw-Hill  Book 


Company,  1982. 

13.  Berget,  Richard  T.,  and  Turner,  Tim.  “Command  and  Data  Handling,”  Space  Mission 
Analysis  and  Design.  Ed.  Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston; 
Microcosm  Inc.  and  Kluwer  Academic  Publishers  (jointly),  1992. 

14.  Bible,  Steven  R.  “The  World  Wide  Web  Amateur  Satellite  Ground  Station,”  Proceedings 
of  the  AMSAT-NA  13th  Space  Symposium.  Newington,  CT;  American  Radio  Relay 
League,  1995. 

15.  Boas,  Maiy  L.  Satellite  Orbit  Analysis  Program  ISO  API  Manual.  The  Aerospace 
Corporation,  El  Segundo,  California,  Apr-96. 

16.  Boden,  Daryl  G.  “Introduction  to  Astrodynamics,”  Space  Mission  Analysis  and  Design. 

Ed.  Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston;  Microcosm  Inc.  and 
Kluwer  Academic  Publishers  (jointly),  1992. 

17.  Bonometti,RJ.,  and  others.  “DARPA  Initiatives  in  Small-satellite  Technology”,  SPIE 
Proceedings;  Small  Satellite  Technology  and  Applications.  Vol.1495;  (1991). 

18.  Broadsky,  R.  F.  “Defining  and  Sizing  Space  Payloads,”  Space  Mission  Analysis  and 
Design.  Ed.  Larson,  Wiley  J.  and  Wertz,  James  R  Torrance  CA  /  Boston;  Microcosm  Inc. 
and  Kluwer  Academic  Publishers  (jointly),  1992. 

19.  Bruno,  Pattan.  Satellite  Systems  Principles  and  Technologies.  NY;  Van  Nostrand  Reinhold, 
1990. 

20.  Chaggaris,  Elias.  Kearfott  Capabihties  in  Space.  Wayne,  NJ;  Kearfott  Guidance  and 
Navigation  Corporation,  1996. 


155 


21.  Chaggaris,  Elias.  Space  Qualified  Kearfott  Inertial  Reference  Unit.  Wayne,  NJ:  Kearfott 
Guidance  and  Navigation  Corporation,  1996. 

22.  Chiang,  J.  J.  and  Kim,  D.  J.  Mechanics  of  Materials.  Boston,  Massachusetts:  PWS 
Engineering,  1984. 

23.  Chow,  Brian  G.  An  Evolutionary  Approach  to  Space  Launch  Commercialization.  Santa 
Monica,  CA;  RAND,  1993. 

24.  Clemen,  Robert  T.  Making  Hard  Decisions:  An  Introduction  To  Decision  Analysis. 
Belmont,  CA:  Duxbury  Press,  1996. 

25.  The  Clementine  Team.  Clementine  n  Concept  Design  Review.  Naval  Research  Laboratory, 
CA.  14-Mar-96. 

26.  Davies,  Richard  S.  “Communication  Architecture,”  Space  Mission  Analysis  and  Design. 
Ed.  Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and 
Kluwer  Academic  Publishers  (jointly),  1992. 

27.  Dawdy,  A.B.  and  Holker,  D.  L.  An  Approach  to  Rapid  Pavload  Integration:  The 
Spacecraft-To-Pavload  Interface  Guideline  (SPIG)  Version  1.  The  Aerospace  Corporation, 
El  Segundo,  California,  Apr-96. 

28.  Day,  Gregory  R.  and  Lewis,  Kelly  D.  “Strength  Analysis”.  Spacecraft  Structures  and 
Mechanisms.  Ed.  Sarafin,  Thomas  P.. Torrance-  California  / Boston:  Microcosm,  Inc.  / 
JCluwer  Academic  Press  (jointly),  1995. 

29.  Department  of  the  Air  Force.  FLTSATCOM  Orbital  Operations  Handbook.  The  U.S.  Air 
Force,  1977. 


156 


30.  Dezelan,  R.  W.  Cost  Savings  Recommendations  for  Warfighters  Integrated  Next 


Generation  Space  Systems  (WINGSSV  The  Aerospace  Corporation,  El  Segimdo, 
California,  Mar-96. 

31.  Dezelan,  R.  W.  Distributed  Satellite  Formation  Alternatives.  The  Aerospace  Corporation, 
El  Segundo,  California,  Mar-96. 

32.  Domheim,  Michael  A.  “  Lockheed  Must  Prove  LLV  Reliability  by  June,”  Aviation  Week 
&  Space  Technology,  :  18-20  (August  21  1995). 

33.  Domheim,  Michael  A.  “  Lockheed  Completes  LLV  Mockup  Stacking,”  Aviation  Week  & 
Space  Technology,  :  69  (August  1, 1994). 

34.  Domheim,  Michael  A.  “  Range  Video  C^tures  LLV-1  Destruction,”  Aviation  Week  & 
Space  Technology,  :  53  (September  4, 1995). 

35.  Domheim,  Michael  A.  “Vectoring,  IMU  Destroyed  LLV-1,”  Aviation  Week  &  Space 
Technology.  :  96-97  (December  18/25, 1995). 

36.  Doukas,  Peter  G,  McCandless,  James  R.,  William  RSarafin,  and  Thomas  P.  “Stmctures 
and  Mechanisms,”  Space  Mission  Analysis  and  Design.  Ed.  Larson,  Wiley  J.  and  Wertz, 
James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer  Academic  Publishers 
(jointly),  1992. 

37.  Doukas,  Peter  G.,  McCandless,  James  R.Britton,  William  RSarafin,  and  Thomas  P. 
“Spacecraft  Configuration  and  Stmctural  Design”.  Fundamentals  of  Space  Systems.  Ed. 
Pisacane,  Vincent  L.  and  Moore,  Robert  C.  New  York:  Oxford  University  Press,  1994. 

38.  Doyle,  Christine.  Space  Inertial  Reference  Unit.  Goleta,  CA:  Litton  Guidance  and  Control 
Systems,  1996. 


157 


39.  Dueber,  Ross  E.  and  McKnight,  Darren  S.  Chemical  Principles  Applied  To  Spacecraft 
Operations.  Malabar,  Florida:  Krieger  Publishing  Comp.,  1993. 

40.  Eshbach,  Ovid  W.  Mathematical  Methods  in  Physical  Sciences.  NY:  John  Wiley  &  Sons, 
1983. 

41.  Etemo,  John  S.  “Attitude  Determination  and  Control,”  Space  Mission  Analysis  and  Design. 
Ed.  Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and 
Kluwer  Academic  Publishers  (jointly),  1992. 

42.  Everett,  James.  Systems  Engineer  for  Small  Explorer  program,  NASA  Goddard  Space 
Flight  Center  Telephone  interview.  3  October  1996. 

43.  Fleeter,  Rick,  and  Warner,  Richard.  “Design  of  Low-Cost  Spacecraft,”  Space  Mission 
Analysis  and  Design.  Ed.  Wertz,  James,  and  Larson,  Wiley.  Torrance,  CA:  Microcosm, 
Inc.,  1992. 

44.  Fleeter,  Rick.  “Reducing  Spacecraft  Cost,”  Reducing  Space  Mission  Cost.  Ed.  Wertz, 
James,  and  Larson,  Wiley.  Torrance,  CA:  Microcosm,  Inc.,  1996. 

45.  Ford,  John.  “Communications,”  Space  Mission  Analysis  and  Design.  Ed.  Larson,  Wiley  J. 
and  Wertz,  James  R.  Torrance  CA  /  Boston;  Microcosm  hic.  and  Kluwer  Academic 
Publishers  (jointly),  1992. 

46.  Gere,  James  M.  and  Timoshenko,  Stephen  P.  Mechanics  of  Materials.  USA:  McGraw-Hill 
Book  Company,  1981. 

47.  Gomey,  D.J.,  Blake  J.B.,  Koons,  H.C.,  Schultz,  M.,  and  Vampola,  A.L.  “The  Space 
Environment  and  Survivability,”  Space  Mission  Analysis  and  Design.  Ed.  Larson,  Wiley  J. 
and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer  Academic 
Publishers  (jointly),  1992. 


158 


48.  Hagan,  Joel.  “Space  Technology”.  Electronic  mail.  16:40:14  EST,  11  Octoberl996. 

49.  Hall  in,  Arthur  D.  “Three  Dimensional  Morphology  of  System  Engineering”,  IEEE 
Transactions  on  System  Science  and  Cybernetics.  SSC-5.  No.2:  156-160  (Apr-69). 

50.  Harvey,  E.L.  “Low-cost  Spacecraft  Buses  for  Remote  Sensing  Applications”,  SPIE 
Proceedings:  Small  Satellite  Technology  and  Apphcations,  Vol.  1495:  (1991). 

51.  Hecht,  Herbert.  “Reliability  During  Space  Mission  Concept  Exploration,”  Space  Mission 
Analysis  and  Design.  Ed.  Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston: 
Microcosm  Inc.  and  Kluwer  Academic  Publishers  (jointly),  1992. 

52.  Hecht,  Herbert.  “Reliability  Considerations,”  Reducing  Space  Mission  Cost.  Ed.  Wertz, 
James,  and  Larson,  Wiley.  Torrance,  CA:  Microcosm,  Inc.,  1996. 

53.  Hecht,  H.  and  Hecht,  M.  Reliability  Prediction  for  Spacecraft.  Rome  Air  Development 
Center,  NY.  December  1985  (RADC-TR-85-229) 

54.  Higbee,  Teny  A.  “TECHSTARS:  Small,  Smart  Space  Systems,”  Small-Satellite 
Technology  and  Applications.  103-114.  Washington:  SPIE-The  International  Society  for 
Optical  Engineering,  (4-5  April)  1991. 

55.  High  Performance  Gyro  Assembly.  Guidance  and  Control  for  Space  Applications. 
Teterboro,  NJ:  Allied  Signal  Aerospace,  1996. 

56.  High  Torque  Momentum  Reaction  Wheel  Assembly.  Guidance  and  Control  for  Space 
Applications.  Teterboro,  NJ:  Allied  Signal  Aerospace,  1996. 

57.  Hively,  Will.  “Reinventing  the  Wheel”,  Discover.  .  Aug  96,  pp.  58-68. 

58.  Ithaco  Space  Systems,  1996:  http://www.newspace.com/Industry/Ithaco/home.html. 

59.  Jackson,  Jon  D.  LCOL,  USAF  (SMC/TE)  Telephone  interview.  24  October  1996. 


159 


60.  Jeffrey,  W.  “Small  Satellites  (MSTI-3)  for  Remote  Sensing;  Pushing  the  Limits  of  Sensor 
and  Bus  Technology”,  SPIE  Proceedings:  Platforms  and  Space  Systems.  Vol.  2317. 

(1995). 

61.  Jet  Propulsion  Laboratory.  Flight  Hardware  Survey  (Revision  #  11.  Pasadena,  CA;  Jet 
Propulsion  Laboratory,  1993. 

62.  Kilston,  S.,  and  odiers.  “Multi-mission  Sensor  for  the  RESERVES  Small-satellite 
Program”,  SPIE  Proceedings:  Small  Satellite  Technology  and  Apphcations.  Vol.  1495: 
(1991). 

63.  Kitts,  C.A.  “Initial  Developments  in  the  Stanford  Squirt  Program”,  SPIE  Proceedings: 
Platforms  and  Space  Systems,  Vol.  2317.  1995, 

64.  Kitts,  C.A.  “Integrated  Control  of  Satellite  Payloads”,  SPIE  Proceedings:  Platforms  and 
Space  Systems.  Vol.  2317.  1995, 

65.  Kelements,  H.D.  Air  Force  Satellite  Control  Network  Space  and  Ground  Interface- 
Aerospace  report  No.TOR-0059(61 10-01  )-3.  Contract  No.F04701-88-C-0089.  Satellite 
Control  Network  Directorate  Satellite  Data  Division,  March  1992. 

66.  Kolcum,  Edward  H.  “  NASA,  Pentagon  Chart  Ambitious  Unmanned  Launch  Vehicle 
Program.”  Aviation  Week  &  Space  Technology.  :  131-133  (March  16, 1992). 

67.  Kostishack,  D.F.  “Small-satellite  Sensors  for  Multispectral  Space  Surveillance”,  SPIE 
Proceedings:  Small  Satellite  Technology  and  Applications.  Vol.  1495:  (1991). 

68.  Kramer,  Stuart.  “Application  of  Concept  Moping  To  Systems  Engineering,”  IEEE 
International  Conference  on  Systems.  Man,  and  Cybernetics  Conference  Proceedings.  652- 
654.  New  York:  IEEE  Press,  1990. 

69.  Kramer,  Stuart.  Vector  Dynamics.  Dayton,  OH;  Private  Printing,  1996, 


160 


70.  Landsat.  “Landsat:  What  other  spacecraft  aspire  to  be...  LANDS  AT  spacecraft  and 
network”.  http;//17oe01. atsc.allied.com/mainpage.html. 

71.  Larson, Wiley  J.  and  Wertz,  James  R.  “The  Space  Mission  Analysis  and  Design  Process,” 
Space  Mission  Analysis  and  Design.  Ed.  Wertz,  James,  and  Larson,  Wiley.  Torrance,  CA: 
Microcosm,  Inc.,  1992. 

72.  Larson,Wiley  J.  and  Wertz,  James  R.  Reducing  Space  Mission  Costs.  Torrance,  California; 
Microcosm  Press,  1996. 

73.  Lenorovitz,  Jeffrey  M.  “  January  Pegasus  Launch  Key  to  Mission  Rate  Build-Up,” 
Aviation  Week  &  Space  Technology.  :  69  (December  7, 1992). 

74.  Leritz,  John  E.  and  Palmer,  Donald  L.  “Mechanics  of  Materials”.  Spacecraft  Structures 
and  Mechanisms.  Ed.  Sarafin,  Thomas  P.  .Torrance-  California  /  Boston:  Microcosm,  Inc.  / 
Kluwer  Academic  Press  (jointly),  1995. 

75.  Lockheed  Martin.  Lockheed  Martin  Launch  Vehicle  (LMLV)  Capabilities  Summary, 

1996. 

76.  London  HI,  John  R.  Leo  On  the  Cheap.  Air  University  press,  Maxwell  AF  Base,  Alabama, 
Oct.  1994. 

77.  Low  Cost  Gyro  Assembly.  Guidance  and  Control  for  Space  Applications.  Teterboro,  NJ: 
Allied  Signal  Aerospace,  1996. 

78.  Low  Cost  Momentum  Wheel  Assembly.  Guidance  and  Control  for  Space  Applications. 
Teterboro,  NJ:  Allied  Signal  Aerospace,  1996. 

79.  Maquire,  Dick.  Handbook  of  Engineering  Fundamentals.  USA;  John  Wiley  &  Sons,  1975. 

80.  McCall,  G.,  and  others.  New  World  Vistas:  Air  and  Space  Power  for  the  21st  Century, 
Summary  Volume.  Air  Force  Scientific  Advisory  Board,  Albuquerque,  1995. 


161 


81.  McDermott,  Joseph  K.  “Power,”  Space  Mission  Analysis  and  Design.  Ed.  Larson,  Wiley  J. 
and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer  Academic 
Publishers  (jointly),  1992. 

82.  McMordie,  Robert  K.  “Thermal,”  Space  Mission  Analysis  and  Design.  Ed.  Larson,  Wiley 
J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer  Academic 
Publishers  (jointly),  1992. 

83.  McMordie,  Robert  K.  “Configuring  a  Spacecraft,”  Spacecraft  Structures  and  Mechanisms 
Torrance-  California  /  Boston:  Microcosm,  Inc.  /  Kluwer  Academic  Press  (jointly),  1 995. 

84.  Mensa,  DeanL.  High  Resolution  RADAR  Imaging.  Norwood,  MA:  Artech  House,  1981. 

85.  Meyers,  Marc  A.  and  Chawla,  Krishan  K.  “Conceptual  Design  of  Structures,”  Spacecraft 
Structures  and  Mechanisms.  Torrance-  California  /  Boston:  Microcosm,  Inc.  /  Kluwer 
Academic  Press  (jointly),  1995. 

86.  MightySat  Program  Office.  Statement  of  Work  Appendix  A  Technical  Requirements 
Document  ITRDI  for  the  MightvSat  Phase  n  Program  (Revision  31.  Phillips  Laboratory, 
Kirtland  AFB,  New  Mexico.  19-Apr-96. 

87.  Miniature  Inertial  Measurement  Unit.  Honeywell  Satellite  Systems.  Glendale,  AZ: 
Honeywell  Space  Systems  Inc.,  1996. 

88.  “Model  Error  Led  to  Pegasus  Failure,”  Aviation  Week  &  Space  Technology.  :  28  (August 
1  1994). 

89.  Morgan,  Walter  L.and  Gordon,  Gary  D.  Principles  of  Communication  Satellites.  New 
York:  John  Wiley  and  Sons,  Inc.  1993. 

90.  Mosard,  Gil  R.  "A  Generalized  Framework  and  Methodology  for  Systems  Analysis,"  IEEE 
Transaction  on  Engineering  Management  EM-29:  81-87  (Aug  1982). 


162 


91.  Mosier,  M.R.,  and  others.  “Pegasus  Air-launched  Space  Booster  Payload  Interfaces  and 
Processing  Procedures  for  Small  Optical  Payloads,”  SPIE  Proceedings:  Small  Satellite 
Technology  and  Applications.  Vol.  1495:  (1991). 

92.  Muolo,  Michael  J.  Space  Handbook:  An  Analyst's  Guide.  Air  Uniyersity  press.  Maxwell 
AFB,  AL;  Air  Uniyersity  Press,  Dec  1993. 

93.  Muolo,  Michael  J.  Space  Handbook:  A  Warfighter's  Guide  to  Space  (Vol.  IV  Maxwell 
AFB,  AL:  Air  Uniyersity  Press,  Dec  1993. 

94.  Myers,  Raymond  H.  and  Montgomery,  Douglas  C.  Response  Surface  Methodology.  New 
York:  Jon  Wiley  &  Sons,  Inc.,  1995. 

95.  The  NASA  Home  Page,  1996:  http:www.nasa.goy. 

96.  The  NASA,  ASUSat  Homepage,  1996:  enws229.eas.asu.edu/asusat/asusat.shtml 

97.  The  NASA/JPL  Imaging  Radar  Home  Page.  “The  NASA/JPL  Imaging  Radar  Home 
Page”.  http://southport.jpl.nasagoy/desc/im^ingradary3  .html. 

98.  The  NASA/JPL  SAR.  “Miscellaneous  issues  on  Synthetic  Aperture  RADAR  (SAR)”. 
http  ://southport.jpl.nasa.  goy/. 

99.  NASA  Launch  Task  Group.  Future  of  the  US  Space  Launch  Capability:  A  Task  Group 
Report.  NASA,  Washington,  DC,  Noy-92. 

100. NASA  Scientific  and  Technical  Information  Office.  Technical  Memorandum  4679: 
Space-borne  Synthetic  Aperture  RADAR:  Current  Status  and  Future  Directions.  NASA, 
Washington,  DC,  1995. 

101.  The  NASA  Small  Explorer  Program,  1996:  www.laafb.af  mil/SMC. 


163 


102. Negron,  David  and  Chomas,  Arthur.  “Mission  Operations,”  Space  Mission  Analysis  and 
Design.  Ed.  Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc. 
and  Kluwer  Academic  Publishers  (jointly),  1992. 

103. Neter,  John  and  others.  Applied  Linear  Statistical  Models.  USA:  Richard  D.  Edwin, 

Inc.,  1990. 

104. Nguyen,  P.,  and  others.  Unmanned  Space  Vehicle  Cost  Model.  7th  ed.  Space  And  Missile 
Systems  Center,  Los  Angeles,  1994. 

105. Nicastri,  Edward  (Col.  USAF  Retiered).  Former  Director  of  DARPA's  ATSSB  program. 
Telephone  interview.  5  June  1996. 

106. Nicastri,  Edward  (Col.  USAF  Retiered).  Former  Director  of  DARPA's  ATSSB  program. 
Telephone  interview.  30  July  1996. 

107. Nicastri,  Edward  (Col.  USAF  Retiered).  “Tactical  Maneuvering,  Payload  Sizing,  and 
Reliability  issues”.  Electronic  mail.  18:43:22  EST,  22  October 1996. 

lOS.Nozetto,  S.  and  others.  “Clementine  Engineering  and  Technology  Workshop,” 
Proceedings  of  The  Clementine  Program’s  Engineering  and  Technology  Workshop. 
Washington  DC:  Department  Of  Defense  Ballistic  Missile  Defense  Organization,  26  July 
1994. 

109.O'Neil,  J.,  and  others.  “Eagle-class  Small  Satellite  for  LEO  Applications”,  SPIE 
Proceedings:  Small  Satellite  Technology  and  Applications.  Vol.  1495:  (1991). 
llO.Orbital  Sciences  Corporation,  1996:  http://www.orbital.com. 

111. Orbital  Science  Corporation.  Commercial  Pegasus  Payload  User’s  Guide.  OflSce  of 
Launch  Vehicle,  Business  Development,  Pegasus  Launch  Vehicle  Systems,  Dulles, 
Virginia.  1 -Oct-93. 


164 


112.0rbital  Science  Corporation.  Commercial  Taurus  launch  Vehicle  Payload  User's  Guide. 


Office  of  Launch  Vehicle,  Business  Development,  Taurus  Launch  Vehicle  Systems, 
Dulles,  Virginia.  18-Apr-96. 

113. “  Pegasus  Carrier  Aircraft  Completes  Flight  Tests,”  Aviation  Week  &  Space  Technology. 

;  57-58  (December  6, 1993). 

114. Pegasus  Marketing  Video.  Prod.  Orbital  Science  Corporation.  Dulles,  Virginia.  1995. 

115. Peery,  David  J.  and  Azar,  J.  J.  Mechanical  Metallurgy.  Englewood  Cliffs,  NJ:  Prentice- 
Hall,  Inc.,  1984. 

1 16. Pohl,  Ed.  Class  handout,  SENG  520.  School  of  Engineering,  Air  Force  Institute  of 
Technology,  WPAFB  OH.  6-Oct-95. 

llV.Presley,  S.P.,  Agardy,  F.J.,  and  Berrier,  D.J.  An  Appoach  To  Rapid  Payload  Integration: 
The  Spacecraft-To-Pavload  Interface  Guideline  ISPIGY  The  Aerospace  Corporation,  El 
Segundo,  CA.  8-Apr-96. 

118. Rademacher,  Joel.  “NASA  Small  Explorer  (SMEX)  Home  page:  NASA  Small  Explorer 
Program,”  1996:  sunland.gsfc.nasa.gov/smex/smexhomepage.html. 

119. Rademacher,  Joel.  “Phillips  Laboratory,”  1996:  enws229.eas.asu.edu/joel/joel.shtml 

120. Ramakumar,  R.  Engineering  Reliability  -  Fundamentals  &  Applications.  Englewood  Cliffs 
CA:  Prentice  Hall,  1993. 

121.  Rash,  James  L.  Third  International  Symposium  on  Space  Missions  and  Ground  Data 
Systems  Part  I/H.  Greenbelt,  Maryland:  NASA,  Nov  15-18, 1994. 

122. Reaction  Wheel  and  Momentum  Wheel  Assemblies.  Space  Systems  -  Momentum  Control. 
Glendale,  AZ:  Honeywell  Space  Systems  Inc.,  1996. 


165 


123  .Rees,  W.G.  Physical  Principles  of  Remote  Sensing.  Cambridge:  Cambridge  Univ.  Press, 
1990. 

124. Reeves,  Emery  “Spacecraft  Design  and  Sizing,”  Space  Mission  Analysis  and  Design.  Ed. 
Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer 
Academic  Publishers  (jointly),  1992. 

125. Reeyes,  Emery  “Spacecraft  Manufacture  and  Test,”  Space  Mission  Analysis  and  Design. 
Ed.  Larson,  Wiley  J.  and  Wertz,  James  R  Torrance  CA  /  Boston:  Microcosm  Inc.  and 
Kluwer  Academic  Publishers  (jointly),  1992. 

126. Reichhardt,  Tony.  “  Launch  Woes  Ground  NASA  Science  Spacecraft,”  Naure.  45.717 
(August  31,  1995). 

127. Reinert,  Richard  P.  and  Wertz  James  R.  “Mission  Characterization,”  Space  Mission 
Analysis  and  Design.  Ed.  Larson,  Wiley  J.  and  Wertz,  James  R..  Torrance  CA  /  Boston: 
Microcosm  Inc.  and  Kluwer  Academic  Publishers  (jointly),  1992. 

128. Reynolds,  William  C.  and  Perkins,  Henry  C.  Tactical  Support  Satellite/Standard  Payload 
Interface  (TSS/SPI)  Study:  Standard  Interface  Definitions  and  Cost  Comparisons.  The 
Aerospace  Corporation,  El  Segundo,  California,  Sep-94. 

129.Sackheim,  Robert  L.  “Space  Propulsion  System,”  Space  Mission  Analysis  and  Design.  Ed. 
Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer 
Academic  Publishers  (jointly),  1992. 

ISO.Sarafin,  Thomas  P.,  Heymans,  Robert  J.Wendt,  Robert  G.  Jr.,  and  Sabin,  Robert  V. 
“Thermal  Effects,”  Spacecraft  Structures  and  Mechanisms.  Ed.  Sarafin,  Thomas 
P.. Torrance-  California  /  Boston:  Microcosm,  Inc.  /  Kluwer  Academic  Press  (jointly), 

1995. 


166 


ISl.Sarafin,  Thomas  P.  AIAA  Aerospace  Design  Engineers  Guide.  American  Institute  of 


Aeronautics  and  Astronautics,  Inc.,  Washington  DC,  1993. 

132.Scott,  Pace.  US  Access  to  Space  Launch  Vehicle  Choices  for  1990-2010.  RAND  Santa 
Monica,  CA,  Mar-90. 

13 3. Sellers,  Jerry,  and  Milton,  Ed.  “Technology  for  Reduced  Cost  Missions,”  Reducing  Space 
Mission  Cost.  Ed.  Wertz,  James,  and  Larson,  Wiley.  Torrance,  CA:  Microcosm,  Inc., 

1996. 

134.Servo  Space  Systems,  1996:  http://www.servo.com/spasys.html. 

13 5. Shuster,  Malcolm  D.  Fundamentals  of  Space  Systems.  New  York  :  Oxford  University 
Press,  1994. 

136.Skullney,  W.  E.  “Spacecraft  Thermal  Control”.  Fundamentals  of  Space  Systems.  Ed. 
Pisacane,  Vincent  L.  and  Moore,  Robert  C.  New  York:  Oxford  University  Press,  1994. 

13  7.  Smith,  Bruce  A.  “  Orbital  L-101 1  Ready  for  First  Launch,”  Aviation  Week  &  Space 
Technology,  :  30  (July  4,  1994). 

138. Smith,  Bruce  A.  “  OSC  Seeks  Cause  of  Pegasus  XL  Failure,”  Aviation  Week  &  Space 
Technology,  :  (1994). 

139.Smith,  Bruce  A.  “  Pegasus  XL  Success  Opens  Door  to  Fast-Paced  Launch  Schedule,” 
Aviation  Week  &  Space  Technology,  :  26-27  (March  18, 1996). 

140.  Space  &  Missile  Systems  Center,  Orbital  Sciences  Corporation's  (OSC's)  Home  Page, 
1996:  www.orbital.com 

141.  Space  Systems  Division.  Pegasus  Design  Safety  Requirements  Document.  Orbital  Science 
Corporation,  Fairfax,  Virginia,  27-May-92. 


167 


142.Stanford  SSDL  Home  Page.  “Stanford  SSDL  Home  Page.  Space  System  Design  at 
Stanford  University,  http://aa.stanford.edu/~ssdl/. 

143.Stodden,  David  Y.  and  Galasso,  Gina  D.  Ensdneering  Theromodvnamics.  USA;  McGraw- 
Hill  Book  Company,  1977. 

144.Sutton,  George  P.  Rocket  Propulsion  Elements.  New  York;  Jonh  Wiley  and  Sons,  1992. 

145.  Taurus  Marketing  Video.  Prod.  Orbital  Science  Corporation.  Dulles,  Virginia.  1996. 

146. Telemetry  Components  and  Systems,  Command,  Control  and  Communications  Catalog. 
Newtown,  PA.  AYDIN  VECTOR,  1996. 

147. The  Aerospace  Corporation.  Communications  Satellites  1958-1992.  El  Segundo, 
California:  The  Aerospace  Corporation,  1991. 

148. U.S.  Air  Force  Home  Page,  1996:  http://www.af  mil. 

149. U.S.  Congress,  Office  of  Tecnology  Assesment.  Aifordabble  Spacecraft  Design  and 
Launch  Alternatives.  Washington,  DC:  US  printing  Office.  (OTA-BP-ISC-60) 

150. Vesely,  David.  “Transcript :  DOD  News  Briefing  :  Major  General  David  Vesely,  14th  Air 
Force  Commander.  Miscellaneous  in-theater  space  operations  concepts”. 
http://www.laafb.af  mil/SMC/CZ/homepage/news/dodnewl3.htm. 

151. Velocci,  Anthony  L.  “  Orbital  Says  Human  Error  Caused  Pegasus  XL  Loss,”  Aviation 
Week  &  Space  Technology,  :  60  (September  4, 1995). 

152.  Walker,  Kevin  J.  Systems  Analysis  of  GPS  Electrical  Power  System  Redesign.  MS  thesis, 
AFIT/ENY/AFrr/GSO/ENY/95D-03.  School  of  Engineering,  Air  Force  Institute  of 
Technology,  WPAFB  OH,  Dec-95. 

153.  Warner,  Richard.  Founder  and  Chief  Technical  Officer  of  AeroAstro  Coip.  Personal 
interview.  18  July  1996. 


168 


154.  Wertz,  James  R.  “Mission  Evaluation,”  Space  Mission  Analysis  and  Design.  Ed.  Larson, 
Wiley  J.  and  Wertz,  James  R..  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer 
Academic  Publishers  (jointly),  1992. 

155.  Wertz,  James  R.  “Space  Mission  Geometry,”  Space  Mission  Analysis  and  Design.  Ed. 
Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer 
Academic  Publishers  (jointly),  1992. 

156.  Wertz,  James  R.  “Orbit  and  Constellation  Design,”  Space  Mission  Analysis  and  Design. 
Ed.  Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and 
Kluwer  Academic  Pubhshers  (jointly),  1992. 

157. Wiesel,  William  E.  Spaceflight  Dynamics.  New  York:  McGraw-Hill,  1989. 

15 8.  Williams,  Michael  S.  “Requirements  Definition.”  Space  Mission  Analysis  and  Design.  Ed. 
Larson,  Wiley  J.  and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer 
Academic  Publishers  (jointly),  1992. 

159.  Wingate,  Clarence.  SatAC  Materials  Database  (matter. datV  Phillips  Laboratory,  Kirtland 
AFB,  New  Mexico,  Mar-96. 

160.  Wong,  Robert  “Cost  Modeling,”  Space  Mission  Analysis  and  Design.  Ed.  Larson,  Wiley  J. 
and  Wertz,  James  R.  Torrance  CA  /  Boston:  Microcosm  Inc.  and  Kluwer  Academic 
Publishers  (jointly),  1992. 

161.  Worden,  Col.  Simon  P.,COL,  USAF  (50SW/CC).“Space:  Grabbing  the  Solar  System 
(and  Dominating  the  Planet),”  AF  2025  Submission.  Falcon  AFB,  CO:  «Publisher»,  1996. 


169 


Capt  Gerald  (Gerry)  F.  AsM)y 

After  graduating  from  Riverude  High  School  in  June  19S3,  he  entered  the  enlisted  ranks 
of  the  U.S.  Air  Force.  A  year  later  he  entered  tire  U.S.  A.F  Academy  Preparatory  School 
in  Colorado  Springs,  Colorado.  Upon  graduating  whh  honors,  he  entered  the  U.S.  Air 
Force  Academy  and  joined  the  class  of  1 989.  Four  years  later  on  3 1  May  1 989, 
graduating  in  the  top  15%  of  his  class,  he  recdved  his  degree  in  Engineering  Sciences  of 
Aerospace  Structures  and  his  regular  commistion  in  U.S.  Air  Force. 

Upon  graduation,  he  left  for  pilot  training  at  Williams  AFB,  Arizona  and  after 
unsuccessfii%  completmg  the  program,  he  entered  Undergraduate  Space  Training  at 
Lo’vty  AFB  in  August  1990.  His  next  assignment  was  to  Falcon  AFB  as  a  Launch 
Analyst  for  the  Nsvy*s  UHF  F/0  commumcation  satdlhe  program.  After  leaving  Falcon 
AFB  in  December  1993,  he  transferred  to  Detachment  1,  AFSPC  at  Los  Angeles  AFB, 
Califoniia,  where  he  worked  as  the  main  Air  Force  Space  Command  qx)kesman  within  the 
■  Miliatcom  Joint  Program  Office.  Then  in  May  1995,  he  entered  the  School  of 
Engineering,  Air  Force  Institute  of  Technology. 


Captain  Darren  J.  Buck 


2 


He 


graduated  from  Holy  Cross  High  School  in  Dover,  Delaware  May  1986  and  began  the 
Freshman  Year  Studies  at  the  University  of  Notre  Dame  in  August  1986.  He  graduated 
from  Notre  Dame  with  a  Bachelor  of  Science  degree  in  Mathematics  in  May  1 990 .  He 
recdved  his  commission  on  19  May  1990  after  having  completed  the  Notre  Dame  Air 
Force  Reserve  OfRcer  Training  Corps  (NDAFROTC). 

After  completing  Undergraduate  Space  Training  at  Lowry  AFB,  CO  in  August 
1991,  his  first  asugnment  was  as  a  Satellite  Operations  Crew  Commander  at  the  3rd 
Satellite  Control  Squadron  <3  SCS  -  later  the  3rd  Space  Operations  Squadron  (3  SOPS) 
at  Falcon  AFB,  CO.  His  two  subsequent  assignments,  also  at  Falcon,  were  as  a 
Simulation  Software  Development/QAE  Officer  and  Satellite  Systems  Instructor  for  the 
MZLSTAR  Satellite  Program  at  the  50th  Crew  Training  Squadron  (50  CTS),  and  as 
Group  Operations  Training  Officer  for  MILSTAR  at  the  50th  Operations  Support 
Squadron  (50  OSS).  In  Mtiy  1 995,  he  emered  the  Graduate  Space  Operations  Program  in 
the  School  of  Engineering  at  the  Air  Force  Institute  of  Technology. 


Lieutenant  Robert  Cameal  IV 

He  graduated  fi:om  two  high  schools  in  1988  located  in  Virginia;  Thomas  Jefferson 
School  for  Science  and  Technology,  and  Fairfiuc  High  School.  In  the  Fall  of  1988  he 
entered  the  Prescott,  AZ  campus  of  Embry 'Riddle  Aeronautical  University.  He  graduated 
with  honors  with  a  bachelor's  science  degree  in  electrical  engineering,  with  a  math  minor, 
in  December  1992.  Upon  graduation  he  was  commissioned  second  lieutenant  in  the 
USAF. 

His  first  assignment  was  the  5th  Space  Launch  Squadron  at  Cape  Canaveral  Air 
Station,  where  he  was  involved  in  launching  Titan  IV  rockets.  In  May  1995  he  entered 
the  Air  Force  Institute  of  Technology  at  Wright-Patterson  as  a  masters  candidate  in  space 
operations.  His  follow  on  assignment  is  with  the  Space  Warfim  Center  at  Falcon  AFB. 


Lieutenant  Tansel  Cokuysal 


graduated  from  Mahepe  Military  High  School  in  1987  and  entered  undergraduate  studies 
at  the  Tuildsh  Air  Force  Acadony  in  Istanbul*  Turkey.  He  graduated  with  a  Military  of 
Sdence  degree  in  Aero^jace  Engineering  August  1991 .  Upon  graduation,  he  was 
commissioned  a  Second  Lieutenant  in  Turkish  Air  Force. 

His  first  assignment  was  at  2*^  Main  Jet  Base,  Izmir  Turkey  for  Basic  Jet  Pilot 
Training.  IBs  second  assignment  was  to  3*^  Main  Jet  Base,  Konya  Turkey  for  F-5A/B 
Combat  Readiness  Training.  His  third  assignment  was  to  4'*'  Main  Jet  Base,  Ankara 
Turkey  forF-16  Basic  and  Combat  Readiness  Tnuning.  His  subsequent  assignment  was 
to  9*  Main  Jet  Base,  Balikesir  Turicey  as  a  Wtng-man  in  191^  (Cobra)  Squadron.  In  May 
1995,  he  entered  the  School  of  Engineering ,  Air  Force  Institute  of  Technology. 


^3 


Lieutenant  Ahmet  Tuna  Doninez 


He  graduated  from  Mahepe  Military  High  School,  Izmir  in  1987  and  entered 
undergraduate  studies  at  the  Turkish  Air  Force  Academy  in  Istanbul,  Turicey.  He 
graduated  with  a  Military  of  Science  degree  in  Aerospace  Engineering  August  1991 .  Upon 
graduation,  he  was  commissioned  as  a  Second  Lieutenant  in  Turkish  Air  Force. 

His  first  assignment  was  at  2"^  Main  Jet  Base,  Izmir  Turkey  for  Basic  Jet  Pilot 
Training.  His  second  assignment  was  to  3"*  Main  Jet  Base,  Konya  Turkey  for  F>5A/B 
Combat  Readiness  Training.  His  third  assignment  was  to  1*  Main  Jet  Base,  Eskisehir 
Turkey  for  F-4E  and  RF-4E  Basic  and  Combat  Readiness  Training.  His  subsequent 
assignment  was  to  1*  Main  Jet  Base,  Eskisdiir  Turkey  as  a  Wing>man  in  1 IS"*  Tactical 
Reconnaissance  Squadron.  In  May  1995,  he  entered  the  School  of  Engineering ,  Air  Force 
Institute  of  Technology  to  have  his  Maters  of  Science  degree  in  System  Engineering. 


Capt  Junes  A.  From 

graduated  from  Frank  W .  Cox  High  School  in  198 1  and  entered  undergraduate  studies  at 
the  Univeriily  of  Virginia  in  Charlottesville.  Virginia  in  1982.  He  graduUed  with  a 
Bachelor  of  Sdence  degree  in  Aerospace  Engineering  in  May  1987.  He  received  his 
commission  on  16  May  1987  and  was  a  Kstinguishcd  Graduate  from  Reserve  Officer 
Training  Corps. 

His  first  assignment  was  at  Lowry  AFB  for  Undergraduate  Space  Training.  His 
second  assignment  was  to  Peterson  AFB  as  a  Defense  SUeOhe  Communications  System 
phase  in  (DSCS  IQ)  Commander  and  Planner/Analyst  Instructor.  His  subsequent 
assignment  was  to  Buckley  ANOB  as  a  Satellite  Operations  Crew  Commander  and  lUer 
Chief  of  Standardization  and  Evaluation  for  the  Defense  Support  Program.  While  at 
Buckley  AN<fe,  he  earned  a  Masters  of  Arts  degree  in  Space  Systems  Management  from 
Webster  University.  In  May  1995,  he  entered  the  School  of  Engineering,  Air  Force 
Institute  of  technology.  His  follow  on  assignment  is  to  United  States  Space  Command 
Headqqarters  at  Peterson  AFB. 


17S 


graduated  from  Spn^e  Ifigh  School  in  19S7  and  entered  undergraduate  studiea  at  the 
University  of  Southern  CaHfomia  in  Los  Angeles,  California.  He  graduated  with  a 
Bachelorof  Sdeoced^ree  in  Aerospace  En^neering  in  May  1991.  Herecdvedhis 
commission  on  9  May  1991,  having  completed  the  Air  Force  Reserve  Officer  Training 
Corps  (AFROtC)  program. 

His  first  assignment  was  at  Falcon  AFB  as  a  satellite  analyst/instructor.  In  May 
1995,  he  entered  the  School  of  Et^ineering,  Afr  Force  Institute  of  Technology. 


First  Lieutenant  Brian  I.  Robinson 


He  graduated  from  Whitney  M.  Young  High  School  in  1987,  and  earned  a  Bachelor  of 
Science  degree  in  Aerospace  Engineering  with  honors,  and  an  Air  Force  commission 
(Distinguished  Graduate)  from  Tuskegee  University  in  May  1993. 

His  only  assignment  prior  to  AFTT  was  as  an  en^eer  for  the  Than  System 
Program  Office  (now  the  Launch  Programs  System  Program  Office),  Los  Angeles  Air 
Force  Base,  CA,  from  September  1993  to  May  1995.  His  duties  included  managing  the 
(Mooing  development,  production,  acquiution,  and  delivery  of  the  Than  IVs  Solid  Rodcet 
Motors  (SRM),  and  was  present  at  Cape  Canaveral  AS  for  five  Titan  IV  launches,  serving 
as  the  Than  SPO's  system  expert  on  the  Titan  SRMs. 

Lt  Robinson  is  married  to  Lt  Coleen  Y.  Robinson,  USAF. 


1 


177 


REPORT  DOCUMENTATION  PAGE 

Form  Approved  f 

0MB  No.  0704-0188  | 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  oer  response,  including  the  time  tor  reviewing  instructions,  searching  existing  data  sources,  [ 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  colleaion  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspea  of  this  | 
collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services.  Directorate  tor  information  Operations  and  Reoorts,  1215  Jefferson  E 
Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302.  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington,  DC  20503.  | 

1.  AGENCY  USE  ONLY  (Leave  blank)  2.  REPORT  DATE  3.  REPORT  TYPE  AN 

November  1996  Maste 

0  DATES  COVERED 

ris  Thesis 

4.  TITLE  AND  SUBTITLE 

The  Preliminary  Design  of  a  Standardized  Spacecraft  Bus 
for  Small  Tactical  Satellites  (Volume  1) 

5.  FUNDING  NUMBERS 

6.  AUTHOR(S) 

Gerald  F.  Ashby,  Capt,  USAF,  et  al. 

7.  PERFORMING  ORGANIZATION  NAME{S)  AND  ADDRESS(ES) 

Air  Force  Institute  of  Technology,  WPAFB  OH  45433-6583 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

AFIT/GSE/GSO/ENY/96D-1 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Lt  Col  James  Rooney 

Phillips  LaboratoryAA/SM 

3550  Aberdeen  Ave  SE 

KAFB,  NM  87117-5776 

10.  SPONSORING/MONITORING 

AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

12a.  DISTRIBUTION /AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

12b.  DISTRIBUTION  CODE 

A 

13.  ABSTRACT  (Maximum  200  words) 

Current  satellite  design  philosophies  concentrate  on  optimizing  and  tailoring  a  particular  satellite  bus  to 
a  specific  payload  or  mission.  Today's  satellites  take  a  long  time  to  build,  checkout,  and  launch.  An 
alternate  approach  shifts  the  design  paradigm  to  one  that  focuses  on  access  to  space,  enabling 
tactical  deployment  on  demand  and  the  capability  to  put  current  payload  technology  into  orbit,  versus 
several  years  by  today's  standards,  by  which  time  the  technology  is  already  obsolete.  This  design 
study  applied  systems  engineering  methods  to  create  a  satellite  bus  architecture  that  can 
accommodate  a  range  of  remote  sensing  mission  modules.  System-level  and  subsystem-level 
tradeoffs  provided  standard  components  and  satellite  structures,  and  an  iterative  design  approach 
provided  candidate  designs  constructed  with  those  components.  A  cost  and  reliability  trade  study 
provided  initial  estimates  for  satellite  performance.  Modeling  and  analysis  based  upon  the  Sponsor’s 
objectives  converged  the  designs  to  an  optimum  solution.  Major  products  of  this  study  include  not 
only  a  preliminary  satellite  design  to  meet  the  sponsor’s  needs,  but  also  a  software  modeling  and 
analysis  tool  for  satellite  design,  integration,  and  test.  Finally,  the  report  provides  an  initial 
implementation  scheme  and  concept  for  operations  for  the  tactical  support  of  this  satellite  system. 

14.  SUBJECT  TERMS 

Satellite  Bus,  Spacecraft  Design,  Systems  Engineering, 

Modular  Satellite,  Satellite  Subsystems,  Remote  Sensing 

15.  NUM^^F  PAGES 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION 

OF  REPORT 

Unclassified 

18.  SECURITY  CLASSIFICATION 

OF  THIS  PAGE 

Unclassified 

19.  SECURITY  CLASSIFICATION 

OF  ABSTRACT 

Unclassified 

20.  LIMITATION  OF  ABSTRACT 

UL 

MSN  7540-01-280-5500 


Standard  Form  298  (Rev.  2-89) 

Prescribed  by  ANSI  Std  Z39-18 
298-102 


